ACP integration
Connect any ACP-compatible editor to Bob Shell as a first-class AI assistant.
Bob Shell can run as an Agent Client Protocol (ACP) server. When connected, the editor owns the thread UI, permission dialogs, and diffs, while Bob owns the runtime: model access, tools, MCP servers, and shell execution.
ACP plays the same role for coding agents that the Language Server Protocol plays for language tooling: one JSON-RPC contract, many editors, many agents. Local agents communicate with the editor over stdin and stdout.
Supported editors
The following editors support ACP connections to Bob Shell:
- Zed
- IntelliJ IDEA
- Neovim
Getting started
Start Bob Shell as an ACP server:
bob acpThe process waits for JSON-RPC on stdin. Start it through your editor's ACP configuration running it directly in a terminal appears to hang.
Follow your editor's ACP configuration instructions to connect to the bob acp process. For more information about the protocol, see the ACP specification.
Authentication
Bob authenticates during ACP initialization. If BOBSHELL_API_KEY is set in the environment that launches bob acp, Bob uses the key and no further action is required.
Without an API key or a stored token, your editor prompts you to authenticate through SSO. Complete the browser flow once; Bob stores the token so subsequent ACP sessions on the same machine reuse it.
Workspace trust
Bob checks workspace trust before creating a session. An untrusted workspace causes session creation to fail. To trust a workspace, open a terminal in that directory and run Bob Shell interactively:
cd /path/to/project
bobAfter trust is recorded, exit and reconnect through the editor.
For short-lived or disposable environments, pass --trust in your ACP arguments. For tradeoffs, see Command options.
MCP servers
Both the editor and Bob can supply MCP servers to a session. Both sets of servers initialize inside the same Bob session harness, which makes duplicate configuration easy to miss.
Prefer one owner for each MCP server. If an MCP tool is unexpectedly missing, check both your editor's MCP settings and Bob's native MCP configuration.
Each ACP session creates its own harness with its configured MCP servers. A local MCP server may start once per active Bob thread. Monitor resource use before opening many parallel threads, especially when a server starts a JVM, container, or local model.
Bob Shell compared to the editor terminal
Bob Shell executes commands in its own child process, not in your editor's terminal. A command that works in your editor terminal may fail for Bob Shell if the bob acp process inherited a different PATH, working directory, or environment.
Changes you make in a running editor terminal such as cd or export do not reach Bob Shell. If you update the launch environment, restart the ACP thread.
Command options
Start with bob acp and add options only for a specific reason:
| Option | Description |
|---|---|
--log-level <level> | Set the log verbosity: debug, info, warn, error, or silent. Also configurable through the BOB_LOG_LEVEL environment variable. |
--trust | Trust every workspace that this ACP server opens. This option removes a project-level boundary, so do not include it in a permanent editor configuration. |
--auto-approve | Approve every tool call without showing permission prompts. This option is broader than selecting Always allow for a single tool. |
--disable-mcp | Skip MCP server initialization. Use this option to isolate session startup failures. |
--disable-subagents | Omit Bob's subagent tool registration when the task does not require delegation. |
--accept-license | Record license acceptance before server startup. Review the license files first by running bob --show-license acp. |
Using --trust and --auto-approve together removes both the workspace gate and per-tool approval. A prompt can act in any workspace the server opens without further confirmation. Do not include both options in your default editor configuration.