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:

  • You see the full tree before every byte is local. Cold projects hydrate the moment you touch them; hot projects behave like ordinary local directories.
  • 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 under a lease that scopes its authority, budget, and audit.

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.
Agent leasesScoped, audited authority for coding agents working in your projects.
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 login --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. Open a project, and Bowline hydrates it on touch, restores dependencies, and materializes its env. Your edits sync as you go.
  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. A lease scopes what the agent can touch; its output becomes a new Workspace Snapshot or a review-ready change.

Next steps

Pick the path that matches how you want to start.

On this page