Coding agents

A trusted coding agent works in the real project directory by default, the same ~/Code/acme/web you use. Bowline doesn't wrap the agent in a session, a budget, or a bespoke tool surface. Sync makes the workspace a real local directory on every trusted device and agent host — source, config, .env files, and secrets rematerialize as ordinary local files — so you point Claude Code, Codex, or Cursor at a directory and let it work with its own native tools. Bowline's job is to make the right workspace state exist wherever the agent runs, and to give you a review gate when you want one.

The default: the real directory

Point the agent at ~/Code/<project> and let it work. Its edits enter the normal local write log and sync as ordinary workspace state: non-conflicting edits become a new Workspace Snapshot and advance the Workspace Head automatically, the same as any other local edit. No Git publish is required, and there is no completion step — the files are the truth Bowline reads.

If the agent's edits diverge from another device's edits to the same file, the sync engine sets the other side aside as a conflict-aside file instead of merging. Reconciling it is ordinary editing, which the same agent can do.

Opt-in isolation: work views

When you want to see the work before it touches the main project, give the agent a work view instead of the main path.

1. Create one with bowline work create ~/Code/acme/web auth-fix.
2. Point the agent at ~/Code/.work/acme/web/auth-fix. It's a real, cd-able directory with the project's files and inherited env, so the agent works there exactly as it would anywhere else.
3. Review with bowline work review auth-fix and bowline work diff auth-fix, then apply with bowline work accept auth-fix or drop it with bowline work discard auth-fix.

Nothing in a work view reaches the main project until you accept it. The work view is reviewable at any time — there is no agent-driven "ready for review" signal to wait for. Review-ready work surfaces in bowline status --root ~/Code --project <path> and bowline work list (and in bowline tui).

Remote agent hosts

An agent host is just a trusted device. bowline connect <host> installs Bowline over SSH and completes device trust, after which the host has the same real ~/Code — code, env, and secrets included. You then run your agent on that host yourself, pointed at the project directory. See connect remote hosts.

Env and secrets

Trusted devices and agent hosts rematerialize .env files and secrets as real local files, so an agent's build and test commands work without anyone copying credentials. Secret values never belong in prompt text — env key names and file paths are fine, and the agent reads the values from disk like any other tool. Bowline's hosted service cannot read them.

Staying below the product fold

There is no agent workflow console to learn. Humans and agents share the same real ~/Code tree and the same CLI; the only agent-relevant ceremony is the optional work view, and you review an agent's output the same way you review your own work: open the folder, run the tests, and accept or discard.

Next steps

• Work with coding agents: a task guide for local and remote agent work.
• Work views: the review-before-apply primitive.
• Agent-native contract: the CLI contract for driving Bowline from an agent.
• Agent workflows: end-to-end flows.
• Status and health: how attention items and degraded state appear.