Start it

omp acp           # equivalent to: omp --mode acp

The 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 toolACP method
readfs/read_text_file
writefs/write_text_file
bashterminal/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):

MethodReturns
_omp/sessions/listAllPaginated cross-cwd session index.
_omp/projects/listDiscovered project cwds with session counts.
_omp/chats/byCwdSessions filtered by working directory.
_omp/usageToken and cost rollup for active sessions.
_omp/extensionsList discovered extensions.
_omp/extensions/toggleEnable 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 -> out

For 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

Ask Docs

AI assistant to help answer questions about the documentation. Answers are read-only and cite docs/source.

Hi! How can I help you with the documentation today? Answers are read-only and cite docs/source.

Ctrl+Enter to send