# Coding agents (/docs/concepts/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 [#the-default-the-real-directory] Point the agent at `~/Code/` 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](/docs/concepts/conflicts) instead of merging. Reconciling it is ordinary editing, which the same agent can do. Bowline never commits, branches, or pushes for the agent. Git publish is a separate, later step in your own workflow. ## Opt-in isolation: work views [#opt-in-isolation-work-views] When you want to see the work before it touches the main project, give the agent a [work view](/docs/concepts/work-views) 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 ` and `bowline work list` (and in `bowline tui`). ## Remote agent hosts [#remote-agent-hosts] An agent host is just a trusted device. `bowline connect ` 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](/docs/getting-started/connect-remote-hosts). ## Env and secrets [#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 [#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 [#next-steps] * [Work with coding agents](/docs/guides/working-with-agents): a task guide for local and remote agent work. * [Work views](/docs/concepts/work-views): the review-before-apply primitive. * [Agent-native contract](/docs/agents/contract): the CLI contract for driving Bowline from an agent. * [Agent workflows](/docs/agents/workflows): end-to-end flows. * [Status and health](/docs/concepts/status-and-health): how attention items and degraded state appear.