Work with coding agents

This guide walks through handing real work to a coding agent. There is nothing to start or supervise on Bowline's side: you point the agent at a directory, let it work with its own tools, and review the result. You'll also see how to keep an agent's output isolated for review-before-apply and how to spin up a remote agent host. The agent works in the same ~/Code tree you use, so reviewing its output means opening a folder and running tests, not learning a console.

Before you start

You need an Authorized Device with a synced project. Confirm the project is synced first:

bowline status --root ~/Code --project ~/Code/acme/web

If the project hasn't synced yet or has conflict-asides waiting, status reports that as attention. Reconcile any conflicts before handing off so the agent starts from the state you expect.

Hand a task to a local agent

Point your agent — Claude Code, Codex, Cursor — at the real project directory and give it the task in your own words. The project is ordinary local files, .env included, so the agent's build and test commands just work.

cd ~/Code/acme/web
claude "fix the auth callback race"

Let the agent work, then review the result with normal tools. There's no completion step to run: non-conflicting edits already advanced the Workspace Head as the agent wrote them, the same as your own edits.

cd ~/Code/acme/web
pnpm test

Keep output isolated for review

When you want to review before anything touches the main project, give the agent a work view. Its writes stay in an isolated directory under ~/Code/.work until you accept them.

1. Create the work view and point the agent at it:

   bowline work create ~/Code/acme/web auth-fix
   cd ~/Code/.work/acme/web/auth-fix
   claude "fix the auth callback race"

2. Inspect the isolated output once the agent finishes:

   cd ~/Code/.work/acme/web/auth-fix
   bowline work diff auth-fix
   pnpm test

3. Apply it into the main view, or drop it if it's not good:

   bowline work accept auth-fix
   # or
   bowline work discard auth-fix

Spin up a remote agent host

To run an agent on another machine, bootstrap the host first. bowline connect uses your SSH access as transport and Bowline device trust for decrypt authority, leaving the host with the same real ~/Code:

bowline connect linux-server-1

Treat the host as trusted only when the command completes with no blocked steps and reports trusted: true — SSH reachability alone is not workspace trust. Then run your agent on the host yourself, pointed at the project directory:

ssh linux-server-1
cd ~/Code/acme/web
codex

The host has the project's files, env, and secrets rematerialized locally, so the agent works against the same workspace reality you'd have. Its edits sync back like any other device's, and you can hold them for review by having it work in a work view, exactly as above.

Review the work whenever you're ready

There's no signal to wait for. Check status and the work list at any time to see what an agent has done:

bowline status --root ~/Code --project ~/Code/acme/web
bowline work list

Open the output, run the checks you care about, and apply or drop it with bowline work accept or bowline work discard. If bowline work accept finds edits that don't apply cleanly, the work view flips to review-ready with the conflicting paths named, and bowline work review shows what needs a manual look before you can retry the accept.

Next steps

• Coding agents: how agents work in real directories and work views.
• Work views: the review-before-apply mode for agent work.
• Connect remote hosts: more on bowline connect and device trust.
• Agent-native contract: driving Bowline from the agent's side.
• Agent workflows: end-to-end agent flows.