Start it
omp acp # equivalent to: omp --mode acpThe mode flag is listed with every other on the CLI reference. ACP runs over stdio using JSON-RPC framing — spawn omp as a subprocess and connect its stdin/stdout to your client.
Spec: zed-industries/agent-client-protocol. Zed ships first-party ACP support; other editors that implement the protocol can drive omp the same way.
Initialization
ACP does not require a configured model at startup. The client drives initialize, then authenticate, and only then selects a model. When the client opts into clientCapabilities.auth.terminal, omp advertises a terminal auth method that launches the omp TUI to sign in; otherwise the only method is agent — reusing the provider keys and OAuth state already configured under ~/.omp.
What the client sees
When the client advertises filesystem and terminal capabilities at initialize, the agent routes built-in tool I/O through the client. Reads see unsaved buffers; writes land through the editor.
| omp tool | ACP method |
|---|---|
read | fs/read_text_file |
write | fs/write_text_file |
bash | terminal/create + terminal/output (per-call client-side terminals) |
bash calls and destructive edit operations (file deletes and moves) are gated behind session/request_permission when the client supports it. The agent caches allow_always and reject_always per tool for the session’s lifetime, so one approval covers a long edit loop. Plan mode is advertised so clients can flip the agent into proposal-only execution from their UI; tool-call updates carry tool_call_update.locations so editors can follow multi-file edits live.
Slash commands
Most slash commands surface through ACP’s command list, so users get the same /plan, /model, /compact, and so on from inside the editor. Commands without a text handler — the ones that exist only to drive TUI surfaces — are filtered out, and /login and /quit are also hidden (login is owned by ACP’s authenticate step; quitting is the client’s job).
File references (@path) and tool-call cards work the same way they do in the TUI — the editor renders them using ACP’s content-block types.
Mode & config updates
session/set_mode and session/set_session_config_option("mode", …) both emit current_mode_update so the editor stays in sync. /model emits config_option_update after a switch.
Extension methods
Beyond stock ACP, omp exposes a small _omp/* namespace (the leading underscore is the spec’s convention for non-spec methods):
| Method | Returns |
|---|---|
_omp/sessions/listAll | Paginated cross-cwd session index. |
_omp/projects/list | Discovered project cwds with session counts. |
_omp/chats/byCwd | Sessions filtered by working directory. |
_omp/usage | Token and cost rollup for active sessions. |
_omp/extensions | List discovered extensions. |
_omp/extensions/toggle | Enable or disable an extension. |
These let an ACP client browse and reopen prior sessions without re-implementing session discovery; see Sessions for how the underlying tree is laid out.
Debugging the wire
ACP framing is one JSON object per line over stdio, the same shape as RPC, so the same tee trick works:
mkfifo in out
tee acp.in.log < in | omp acp | tee acp.out.log > out &
# point your ACP client at the named pipes
# stdin -> in
# stdout -> outFor one-off inspection, run the editor against omp acp 2>acp.stderr.log. omp writes startup and transport errors to stderr without mixing them into the ACP stream.\n