Skip to content
BMO

Zed Integration

BMO integrates with Zed via two protocols:

  • MCP (bmo serve-mcp) — exposes BMO tools in Zed’s Agent panel
  • ACP (bmo acp) — full Zed Agent Client Protocol integration

Zed status

Section titled “Zed status”

Use the bounded Zed posture surfaces when you want troubleshooting or integration-state output rather than the live transports themselves:

  • bmo config show-zed - config-only posture view for ACP and the existing serve-mcp integration
  • /zed - live TUI summary
  • GET /v1/zed-status - live HTTP summary
  • get_zed_status / bmo_get_zed_status - shared agent and MCP JSON output

The status family keeps the ACP filesystem caveat explicit: BMO records the client capability flags for compatibility, but view, edit, and write still use local disk today.

Quick setup (MCP)

Section titled “Quick setup (MCP)”

The fastest path uses the task zed:configure macro (requires Taskfile):

Terminal window
task zed:configure       # auto-detects the bmo binary and writes ~/.config/zed/settings.json
task zed:print-config    # print the JSON snippet for manual setup

Manual MCP setup

Section titled “Manual MCP setup”

Add to ~/.config/zed/settings.json:

{
  "context_servers": {
    "bmo": {
      "command": {
        "path": "/path/to/bmo",
        "args": ["serve-mcp"],
        "env": {}
      }
    }
  }
}

Restart Zed. The BMO tools appear in the Agent panel.

Using bmo_run from Zed

Section titled “Using bmo_run from Zed”

bmo_run is a special tool you can opt into via options.mcp_server.exposed_tools. It delegates a full coding task to the BMO agent. Use it to kick off multi-step tasks (file edits, bash execution, etc.) from a Zed conversation:

Use bmo_run to refactor the auth module to use JWT

ACP integration

Section titled “ACP integration”
Terminal window
bmo acp

The ACP server exposes BMO as an Agent Client Protocol agent over JSON-RPC 2.0 on stdio. Configure the path in your Zed settings under agents.

Interop note: Current Zed speaks normative ACP on the client (session/new, session/update, via the ACP SDK). bmo acp accepts spec method names and emits session/update when initialize does not set capabilities.legacyNotifications: true. Legacy-only clients can opt into session/notification. Maintainer detail: ACP topic.

ACP uses the same BMO app state as the TUI: sessions, model selection, tool capabilities, staged workflow plans, operator questions, and run events all come from the normal coordinator path. There is no separate ACP config section.

ACP filesystem (FS) capabilities

Section titled “ACP filesystem (FS) capabilities”

When the Zed (or other ACP) client connects with FS capabilities read_text_file and write_text_file, BMO records those capabilities on the ACP session for protocol compatibility. The current ACP runtime still performs agent file reads and writes on local disk, so view, edit, and write do not yet round-trip through editor-buffer-backed fs/read_text_file or fs/write_text_file requests.

Current behavior: Connect Zed with ACP (e.g. bmo acp as the agent command) to share sessions, prompts, plans, tool activity, and operator questions with the editor. File edits still go through local disk today, even when the ACP client advertises FS capabilities.

ACP session surface

Section titled “ACP session surface”

BMO keeps the older ACP notifications for compatibility (stream_chunk, tool_call, tool_call_update, model_state, phase_timeline, runtime_activity) and also emits richer session updates for clients that use them:

  • agent_message_chunk mirrors assistant text deltas.
  • agent_thought_chunk carries safe, user-visible progress/status text only.
  • available_commands_update, current_mode_update, and session_info_update describe the live session.
  • plan reflects the staged workflow phase and current plan artifact.
  • question publishes operator questions from permissions, MCP elicitations, and agent clarification prompts.
  • agent_message_chunk may carry [A2A handoff] summaries when the parent session runs invoke_a2a—observability only; mesh and A2A routing stay on the coordinator tool plane, not over ACP.

Permission questions are routed to upstream ACP session/request_permission prompts when the client supports that method. If the client does not support the method, BMO falls back to the normal question notification. ACP clients can also call questions/list_pending and question/resolve to show and answer pending questions.

Prompt requests may send content_parts; BMO accepts text, image, and file-backed resource_link parts. File resource links are resolved under the configured working directory and go through the same attachment safety checks as other BMO entrypoints. Inline/non-file resource parts are rejected for now.

Custom commands appear in available_commands_update alongside tool capabilities. To run one from ACP, submit /run <command-name-or-id> [args]; BMO expands the command with the same argument substitution and agent/subtask/model metadata used by the TUI, then sends the expanded prompt through the normal coordinator path.

Section titled “Related”