bowline

Introduction

Bowline gives every machine and coding agent the same ~/Code tree, so source, env, and project state follow you while Git stays your tool.

Bowline makes your developer code folder appear and stay useful across every machine and coding agent you authorize. Your source, configuration, .env files, opaque Git state, and in-progress work follow your workspace automatically, with no daily ceremony around Git, dashboards, or manual sync.

The promise: cd ~/Code/acme && pnpm dev works the same on your laptop, your desktop, and a remote agent host. The code is just there.

What Bowline is

Bowline is a developer workspace sync engine. You accept one workspace root (normally ~/Code), and Bowline keeps that whole tree available on every authorized device:

  • Bowline discovers the workspace, materializes the selected project first, and continues the rest in the background. A project marked ready is an ordinary local directory with readable files.
  • Dev junk stays out of the way. Generated folders, dependencies, and caches are classified and skipped, so you sync source-like state, not node_modules.
  • Your environment follows the code. .env, .env.local, and .env.* files are imported, encrypted, synced, and rematerialized where your tools expect them.
  • Agents get a usable workspace. A trusted coding agent works in the real project directory with its own native tools, or in an isolated work view when you want review before apply.

Bowline is not a Git wrapper, a decentralized forge, or a cloud devbox. Git stays your tool for commits, branches, and remotes. Bowline syncs the workspace underneath.

Who it's for

Bowline is for developers who work across more than one machine and for the coding agents they run. If you have ever copied .env files between machines, rebuilt a stale worktree on a fresh box, re-granted secrets to an agent host, or lost uncommitted work that never made it into a commit, Bowline removes that work.

Core concepts

Bowline's model comes from a small set of ideas. Each maps to a concept page.

ConceptWhat it is
Workspace modelSnapshots, heads, and overlays: how project state advances safely.
Sync and continuityNear-continuous snapshots that capture work as you go, not last-writer-wins file sync.
ConflictsHow Bowline preserves both sides when work diverges, and how you repair it.
Env syncHow .env files are imported, merged by key, and rematerialized.
Path policyThe .bowlineignore file for including and excluding paths from sync.
Setup recipesThe .bowlinesetup file for preparing a fresh machine or agent.
Git and source controlWhy .git/ syncs as opaque state and Bowline never runs Git for you.
Device trustHow a new machine or agent host earns workspace decryption access.
Recovery keysWord-based recovery when no authorized device is available.
Work viewsIsolated, review-before-apply project views under ~/Code/.work.
Coding agentsHow agents work in your real project directories and work views.
Status and healthWhat healthy, attention, and limited mean, and when Bowline notifies you.
ArchitectureThe daemon, control plane, byte plane, and encryption model.

How it fits together

A typical first session has a few steps.

  1. Install Bowline and run bowline setup --root ~/Code. Bowline observes your existing workspace without changing it, then reports concrete state.
  2. Approve the device. A new machine authenticates your account, then requests workspace decryption access that an existing trusted device or a Recovery Key grants.
  3. Work normally. Bowline materializes your selected project, restores dependencies, and writes its env before reporting it usable. Your edits sync as you go while the remaining workspace continues in the background.
  4. Add another machine or a remote agent host. Each one gets the same ~/Code tree after one approval.
  5. Hand work to an agent. Point it at the project directory, or at a work view when you want its output held for review before it reaches the main project.

Next steps

Pick the path that matches how you want to start.

On this page