ACP agents
Agent Client Protocol (ACP) sessions let OpenClaw run external coding harnesses (for example Pi, Claude Code, Codex, Cursor, Copilot, OpenClaw ACP, OpenCode, Gemini CLI, and other supported ACPX harnesses) through an ACP backend plugin. If you ask OpenClaw in plain language to “run this in Codex” or “start Claude Code in a thread”, OpenClaw should route that request to the ACP runtime (not the native sub-agent runtime). Each ACP session spawn is tracked as a background task. If you want Codex or Claude Code to connect as an external MCP client directly to existing OpenClaw channel conversations, useopenclaw mcp serve
instead of ACP.
Fast operator flow
Use this when you want a practical/acp runbook:
- Spawn a session:
/acp spawn codex --bind here/acp spawn codex --mode persistent --thread auto
- Work in the bound conversation or thread (or target that session key explicitly).
- Check runtime state:
/acp status
- Tune runtime options as needed:
/acp model <provider/model>/acp permissions <profile>/acp timeout <seconds>
- Nudge an active session without replacing context:
/acp steer tighten logging and continue
- Stop work:
/acp cancel(stop current turn), or/acp close(close session + remove bindings)
Quick start for humans
Examples of natural requests:- “Bind this Discord channel to Codex.”
- “Start a persistent Codex session in a thread here and keep it focused.”
- “Run this as a one-shot Claude Code ACP session and summarize the result.”
- “Bind this iMessage chat to Codex and keep follow-ups in the same workspace.”
- “Use Gemini CLI for this task in a thread, then keep follow-ups in that same thread.”
- Pick
runtime: "acp". - Resolve the requested harness target (
agentId, for examplecodex). - If current-conversation binding is requested and the active channel supports it, bind the ACP session to that conversation.
- Otherwise, if thread binding is requested and the current channel supports it, bind the ACP session to the thread.
- Route follow-up bound messages to that same ACP session until unfocused/closed/expired.
ACP versus sub-agents
Use ACP when you want an external harness runtime. Use sub-agents when you want OpenClaw-native delegated runs.| Area | ACP session | Sub-agent run |
|---|---|---|
| Runtime | ACP backend plugin (for example acpx) | OpenClaw native sub-agent runtime |
| Session key | agent:<agentId>:acp:<uuid> | agent:<agentId>:subagent:<uuid> |
| Main commands | /acp ... | /subagents ... |
| Spawn tool | sessions_spawn with runtime:"acp" | sessions_spawn (default runtime) |
Bound sessions
Current-conversation binds
Use/acp spawn <harness> --bind here when you want the current conversation to become a durable ACP workspace without creating a child thread.
Behavior:
- OpenClaw keeps owning the channel transport, auth, safety, and delivery.
- The current conversation is pinned to the spawned ACP session key.
- Follow-up messages in that conversation route to the same ACP session.
/newand/resetreset the same bound ACP session in place./acp closecloses the session and removes the current-conversation binding.
--bind herekeeps the same chat surface. On Discord, the current channel stays the current channel.--bind herecan still create a new ACP session if you are spawning fresh work. The bind attaches that session to the current conversation.--bind heredoes not create a child Discord thread or Telegram topic by itself.- The ACP runtime can still have its own working directory (
cwd) or backend-managed workspace on disk. That runtime workspace is separate from the chat surface and does not imply a new messaging thread.
- chat surface: where people keep talking (
Discord channel,Telegram topic,iMessage chat) - ACP session: the durable Codex/Claude/Gemini runtime state OpenClaw routes to
- child thread/topic: an optional extra messaging surface created only by
--thread ... - runtime workspace: the filesystem location where the harness runs (
cwd, repo checkout, backend workspace)
/acp spawn codex --bind here: keep this chat, spawn or attach a Codex ACP session, and route future messages here to it/acp spawn codex --thread auto: OpenClaw may create a child thread/topic and bind the ACP session there/acp spawn codex --bind here --cwd /workspace/repo: same chat binding as above, but Codex runs in/workspace/repo
- Chat/message channels that advertise current-conversation binding support can use
--bind herethrough the shared conversation-binding path. - Channels with custom thread/topic semantics can still provide channel-specific canonicalization behind the same shared interface.
--bind herealways means “bind the current conversation in place”.- Generic current-conversation binds use the shared OpenClaw binding store and survive normal gateway restarts.
--bind hereand--thread ...are mutually exclusive on/acp spawn.- On Discord,
--bind herebinds the current channel or thread in place.spawnAcpSessionsis only required when OpenClaw needs to create a child thread for--thread auto|here. - If the active channel does not expose current-conversation ACP bindings, OpenClaw returns a clear unsupported message.
resumeand “new session” questions are ACP-session questions, not channel questions. You can reuse or replace runtime state without changing the current chat surface.
Thread-bound sessions
When thread bindings are enabled for a channel adapter, ACP sessions can be bound to threads:- OpenClaw binds a thread to a target ACP session.
- Follow-up messages in that thread route to the bound ACP session.
- ACP output is delivered back to the same thread.
- Unfocus/close/archive/idle-timeout or max-age expiry removes the binding.
acp.enabled=trueacp.dispatch.enabledis on by default (setfalseto pause ACP dispatch)- Channel-adapter ACP thread-spawn flag enabled (adapter-specific)
- Discord:
channels.discord.threadBindings.spawnAcpSessions=true - Telegram:
channels.telegram.threadBindings.spawnAcpSessions=true
- Discord:
Thread supporting channels
- Any channel adapter that exposes session/thread binding capability.
- Current built-in support:
- Discord threads/channels
- Telegram topics (forum topics in groups/supergroups and DM topics)
- Plugin channels can add support through the same binding interface.
Channel specific settings
For non-ephemeral workflows, configure persistent ACP bindings in top-levelbindings[] entries.
Binding model
bindings[].type="acp"marks a persistent ACP conversation binding.bindings[].matchidentifies the target conversation:- Discord channel or thread:
match.channel="discord"+match.peer.id="<channelOrThreadId>" - Telegram forum topic:
match.channel="telegram"+match.peer.id="<chatId>:topic:<topicId>" - BlueBubbles DM/group chat:
match.channel="bluebubbles"+match.peer.id="<handle|chat_id:*|chat_guid:*|chat_identifier:*>"Preferchat_id:*orchat_identifier:*for stable group bindings. - iMessage DM/group chat:
match.channel="imessage"+match.peer.id="<handle|chat_id:*|chat_guid:*|chat_identifier:*>"Preferchat_id:*for stable group bindings.
- Discord channel or thread:
bindings[].agentIdis the owning OpenClaw agent id.- Optional ACP overrides live under
bindings[].acp:mode(persistentoroneshot)labelcwdbackend
Runtime defaults per agent
Useagents.list[].runtime to define ACP defaults once per agent:
agents.list[].runtime.type="acp"agents.list[].runtime.acp.agent(harness id, for examplecodexorclaude)agents.list[].runtime.acp.backendagents.list[].runtime.acp.modeagents.list[].runtime.acp.cwd
bindings[].acp.*agents.list[].runtime.acp.*- global ACP defaults (for example
acp.backend)
- OpenClaw ensures the configured ACP session exists before use.
- Messages in that channel or topic route to the configured ACP session.
- In bound conversations,
/newand/resetreset the same ACP session key in place. - Temporary runtime bindings (for example created by thread-focus flows) still apply where present.
Start ACP sessions (interfaces)
From sessions_spawn
Use runtime: "acp" to start an ACP session from an agent turn or tool call.
runtimedefaults tosubagent, so setruntime: "acp"explicitly for ACP sessions.- If
agentIdis omitted, OpenClaw usesacp.defaultAgentwhen configured. mode: "session"requiresthread: trueto keep a persistent bound conversation.
task(required): initial prompt sent to the ACP session.runtime(required for ACP): must be"acp".agentId(optional): ACP target harness id. Falls back toacp.defaultAgentif set.thread(optional, defaultfalse): request thread binding flow where supported.mode(optional):run(one-shot) orsession(persistent).- default is
run - if
thread: trueand mode omitted, OpenClaw may default to persistent behavior per runtime path mode: "session"requiresthread: true
- default is
cwd(optional): requested runtime working directory (validated by backend/runtime policy).label(optional): operator-facing label used in session/banner text.resumeSessionId(optional): resume an existing ACP session instead of creating a new one. The agent replays its conversation history viasession/load. Requiresruntime: "acp".streamTo(optional):"parent"streams initial ACP run progress summaries back to the requester session as system events.- When available, accepted responses include
streamLogPathpointing to a session-scoped JSONL log (<sessionId>.acp-stream.jsonl) you can tail for full relay history.
- When available, accepted responses include
Resume an existing session
UseresumeSessionId to continue a previous ACP session instead of starting fresh. The agent replays its conversation history via session/load, so it picks up with full context of what came before.
- Hand off a Codex session from your laptop to your phone — tell your agent to pick up where you left off
- Continue a coding session you started interactively in the CLI, now headlessly through your agent
- Pick up work that was interrupted by a gateway restart or idle timeout
resumeSessionIdrequiresruntime: "acp"— returns an error if used with the sub-agent runtime.resumeSessionIdrestores the upstream ACP conversation history;threadandmodestill apply normally to the new OpenClaw session you are creating, somode: "session"still requiresthread: true.- The target agent must support
session/load(Codex and Claude Code do). - If the session ID isn’t found, the spawn fails with a clear error — no silent fallback to a new session.
Operator smoke test
Use this after a gateway deploy when you want a quick live check that ACP spawn is actually working end-to-end, not just passing unit tests. Recommended gate:- Verify the deployed gateway version/commit on the target host.
- Confirm the deployed source includes the ACP lineage acceptance in
src/gateway/sessions-patch.ts(subagent:* or acp:* sessions). - Open a temporary ACPX bridge session to a live agent (for example
razor(main)onjpclawhq). - Ask that agent to call
sessions_spawnwith:runtime: "acp"agentId: "codex"mode: "run"- task:
Reply with exactly LIVE-ACP-SPAWN-OK
- Verify the agent reports:
accepted=yes- a real
childSessionKey - no validator error
- Clean up the temporary ACPX bridge session.
- Keep this smoke test on
mode: "run"unless you are intentionally testing thread-bound persistent ACP sessions. - Do not require
streamTo: "parent"for the basic gate. That path depends on requester/session capabilities and is a separate integration check. - Treat thread-bound
mode: "session"testing as a second, richer integration pass from a real Discord thread or Telegram topic.
Sandbox compatibility
ACP sessions currently run on the host runtime, not inside the OpenClaw sandbox. Current limitations:- If the requester session is sandboxed, ACP spawns are blocked for both
sessions_spawn({ runtime: "acp" })and/acp spawn.- Error:
Sandboxed sessions cannot spawn ACP sessions because runtime="acp" runs on the host. Use runtime="subagent" from sandboxed sessions.
- Error:
sessions_spawnwithruntime: "acp"does not supportsandbox: "require".- Error:
sessions_spawn sandbox="require" is unsupported for runtime="acp" because ACP sessions run outside the sandbox. Use runtime="subagent" or sandbox="inherit".
- Error:
runtime: "subagent" when you need sandbox-enforced execution.
From /acp command
Use /acp spawn for explicit operator control from chat when needed.
--mode persistent|oneshot--bind here|off--thread auto|here|off--cwd <absolute-path>--label <name>
Session target resolution
Most/acp actions accept an optional session target (session-key, session-id, or session-label).
Resolution order:
- Explicit target argument (or
--sessionfor/acp steer)- tries key
- then UUID-shaped session id
- then label
- Current thread binding (if this conversation/thread is bound to an ACP session)
- Current requester session fallback
Unable to resolve session target: ...).
Spawn bind modes
/acp spawn supports --bind here|off.
| Mode | Behavior |
|---|---|
here | Bind the current active conversation in place; fail if none is active. |
off | Do not create a current-conversation binding. |
--bind hereis the simplest operator path for “make this channel or chat Codex-backed.”--bind heredoes not create a child thread.--bind hereis only available on channels that expose current-conversation binding support.--bindand--threadcannot be combined in the same/acp spawncall.
Spawn thread modes
/acp spawn supports --thread auto|here|off.
| Mode | Behavior |
|---|---|
auto | In an active thread: bind that thread. Outside a thread: create/bind a child thread when supported. |
here | Require current active thread; fail if not in one. |
off | No binding. Session starts unbound. |
- On non-thread binding surfaces, default behavior is effectively
off. - Thread-bound spawn requires channel policy support:
- Discord:
channels.discord.threadBindings.spawnAcpSessions=true - Telegram:
channels.telegram.threadBindings.spawnAcpSessions=true
- Discord:
- Use
--bind herewhen you want to pin the current conversation without creating a child thread.
ACP controls
Available command family:/acp spawn/acp cancel/acp steer/acp close/acp status/acp set-mode/acp set/acp cwd/acp permissions/acp timeout/acp model/acp reset-options/acp sessions/acp doctor/acp install
/acp status shows the effective runtime options and, when available, both runtime-level and backend-level session identifiers.
Some controls depend on backend capabilities. If a backend does not support a control, OpenClaw returns a clear unsupported-control error.
ACP command cookbook
| Command | What it does | Example |
|---|---|---|
/acp spawn | Create ACP session; optional current bind or thread bind. | /acp spawn codex --bind here --cwd /repo |
/acp cancel | Cancel in-flight turn for target session. | /acp cancel agent:codex:acp:<uuid> |
/acp steer | Send steer instruction to running session. | /acp steer --session support inbox prioritize failing tests |
/acp close | Close session and unbind thread targets. | /acp close |
/acp status | Show backend, mode, state, runtime options, capabilities. | /acp status |
/acp set-mode | Set runtime mode for target session. | /acp set-mode plan |
/acp set | Generic runtime config option write. | /acp set model openai/gpt-5.2 |
/acp cwd | Set runtime working directory override. | /acp cwd /Users/user/Projects/repo |
/acp permissions | Set approval policy profile. | /acp permissions strict |
/acp timeout | Set runtime timeout (seconds). | /acp timeout 120 |
/acp model | Set runtime model override. | /acp model anthropic/claude-opus-4-6 |
/acp reset-options | Remove session runtime option overrides. | /acp reset-options |
/acp sessions | List recent ACP sessions from store. | /acp sessions |
/acp doctor | Backend health, capabilities, actionable fixes. | /acp doctor |
/acp install | Print deterministic install and enable steps. | /acp install |
/acp sessions reads the store for the current bound or requester session. Commands that accept session-key, session-id, or session-label tokens resolve targets through gateway session discovery, including custom per-agent session.store roots.
Runtime options mapping
/acp has convenience commands and a generic setter.
Equivalent operations:
/acp model <id>maps to runtime config keymodel./acp permissions <profile>maps to runtime config keyapproval_policy./acp timeout <seconds>maps to runtime config keytimeout./acp cwd <path>updates runtime cwd override directly./acp set <key> <value>is the generic path.- Special case:
key=cwduses the cwd override path.
- Special case:
/acp reset-optionsclears all runtime overrides for target session.
acpx harness support (current)
Current acpx built-in harness aliases:claudecodexcopilotcursor(Cursor CLI:cursor-agent acp)droidgeminiiflowkilocodekimikiroopenclawopencodepiqwen
agentId unless your acpx config defines custom agent aliases.
If your local Cursor install still exposes ACP as agent acp, override the cursor agent command in your acpx config instead of changing the built-in default.
Direct acpx CLI usage can also target arbitrary adapters via --agent <command>, but that raw escape hatch is an acpx CLI feature (not the normal OpenClaw agentId path).
Required config
Core ACP baseline:- Discord:
channels.discord.threadBindings.spawnAcpSessions=true
Plugin setup for acpx backend
Install and enable plugin:acpx command and version configuration
By default, the bundled acpx backend plugin (acpx) uses the plugin-local pinned binary:
- Command defaults to the plugin-local
node_modules/.bin/acpxinside the ACPX plugin package. - Expected version defaults to the extension pin.
- Startup registers ACP backend immediately as not-ready.
- A background ensure job verifies
acpx --version. - If the plugin-local binary is missing or mismatched, it runs:
npm install --omit=dev --no-save acpx@<pinned>and re-verifies.
commandaccepts an absolute path, relative path, or command name (acpx).- Relative paths resolve from OpenClaw workspace directory.
expectedVersion: "any"disables strict version matching.- When
commandpoints to a custom binary/path, plugin-local auto-install is disabled. - OpenClaw startup remains non-blocking while the backend health check runs.
Automatic dependency install
When you install OpenClaw globally withnpm install -g openclaw, the acpx
runtime dependencies (platform-specific binaries) are installed automatically
via a postinstall hook. If the automatic install fails, the gateway still starts
normally and reports the missing dependency through openclaw acp doctor.
Plugin tools MCP bridge
By default, ACPX sessions do not expose OpenClaw plugin-registered tools to the ACP harness. If you want ACP agents such as Codex or Claude Code to call installed OpenClaw plugin tools such as memory recall/store, enable the dedicated bridge:- Injects a built-in MCP server named
openclaw-plugin-toolsinto ACPX session bootstrap. - Exposes plugin tools already registered by installed and enabled OpenClaw plugins.
- Keeps the feature explicit and default-off.
- This expands the ACP harness tool surface.
- ACP agents get access only to plugin tools already active in the gateway.
- Treat this as the same trust boundary as letting those plugins execute in OpenClaw itself.
- Review installed plugins before enabling it.
mcpServers still work as before. The built-in plugin-tools bridge is an
additional opt-in convenience, not a replacement for generic MCP server config.
Permission configuration
ACP sessions run non-interactively — there is no TTY to approve or deny file-write and shell-exec permission prompts. The acpx plugin provides two config keys that control how permissions are handled: These ACPX harness permissions are separate from OpenClaw exec approvals and separate from CLI-backend vendor bypass flags such as Claude CLI--permission-mode bypassPermissions. ACPX approve-all is the harness-level break-glass switch for ACP sessions.
permissionMode
Controls which operations the harness agent can perform without prompting.
| Value | Behavior |
|---|---|
approve-all | Auto-approve all file writes and shell commands. |
approve-reads | Auto-approve reads only; writes and exec require prompts. |
deny-all | Deny all permission prompts. |
nonInteractivePermissions
Controls what happens when a permission prompt would be shown but no interactive TTY is available (which is always the case for ACP sessions).
| Value | Behavior |
|---|---|
fail | Abort the session with AcpRuntimeError. (default) |
deny | Silently deny the permission and continue (graceful degradation). |
Configuration
Set via plugin config:Important: OpenClaw currently defaults topermissionMode=approve-readsandnonInteractivePermissions=fail. In non-interactive ACP sessions, any write or exec that triggers a permission prompt can fail withAcpRuntimeError: Permission prompt unavailable in non-interactive mode. If you need to restrict permissions, setnonInteractivePermissionstodenyso sessions degrade gracefully instead of crashing.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
ACP runtime backend is not configured | Backend plugin missing or disabled. | Install and enable backend plugin, then run /acp doctor. |
ACP is disabled by policy (acp.enabled=false) | ACP globally disabled. | Set acp.enabled=true. |
ACP dispatch is disabled by policy (acp.dispatch.enabled=false) | Dispatch from normal thread messages disabled. | Set acp.dispatch.enabled=true. |
ACP agent "<id>" is not allowed by policy | Agent not in allowlist. | Use allowed agentId or update acp.allowedAgents. |
Unable to resolve session target: ... | Bad key/id/label token. | Run /acp sessions, copy exact key/label, retry. |
--bind here requires running /acp spawn inside an active ... conversation | --bind here used without an active bindable conversation. | Move to the target chat/channel and retry, or use unbound spawn. |
Conversation bindings are unavailable for <channel>. | Adapter lacks current-conversation ACP binding capability. | Use /acp spawn ... --thread ... where supported, configure top-level bindings[], or move to a supported channel. |
--thread here requires running /acp spawn inside an active ... thread | --thread here used outside a thread context. | Move to target thread or use --thread auto/off. |
Only <user-id> can rebind this channel/conversation/thread. | Another user owns the active binding target. | Rebind as owner or use a different conversation or thread. |
Thread bindings are unavailable for <channel>. | Adapter lacks thread binding capability. | Use --thread off or move to supported adapter/channel. |
Sandboxed sessions cannot spawn ACP sessions ... | ACP runtime is host-side; requester session is sandboxed. | Use runtime="subagent" from sandboxed sessions, or run ACP spawn from a non-sandboxed session. |
sessions_spawn sandbox="require" is unsupported for runtime="acp" ... | sandbox="require" requested for ACP runtime. | Use runtime="subagent" for required sandboxing, or use ACP with sandbox="inherit" from a non-sandboxed session. |
| Missing ACP metadata for bound session | Stale/deleted ACP session metadata. | Recreate with /acp spawn, then rebind/focus thread. |
AcpRuntimeError: Permission prompt unavailable in non-interactive mode | permissionMode blocks writes/exec in non-interactive ACP session. | Set plugins.entries.acpx.config.permissionMode to approve-all and restart gateway. See Permission configuration. |
| ACP session fails early with little output | Permission prompts are blocked by permissionMode/nonInteractivePermissions. | Check gateway logs for AcpRuntimeError. For full permissions, set permissionMode=approve-all; for graceful degradation, set nonInteractivePermissions=deny. |
| ACP session stalls indefinitely after completing work | Harness process finished but ACP session did not report completion. | Monitor with ps aux | grep acpx; kill stale processes manually. |