Does this work out of the box?
Yes, after installing the official ACP runtime plugin:extensions/acpx workspace plugin after
pnpm install. Run /acp doctor for a readiness check.
OpenClaw only teaches agents about ACP spawning when ACP is truly usable:
ACP must be enabled, dispatch must not be disabled, the current session must
not be sandbox-blocked, and a runtime backend must be loaded and healthy. If
any condition fails, ACP skills and sessions_spawn ACP guidance stay hidden
so the agent does not suggest an unavailable backend.
ACP policy changes apply without restarting the Gateway. Enablement, dispatch,
the default agent, and allowed agents govern new admissions; backend and fallback
settings govern subsequent turns. Admitted turns retain their session ownership.
The ACPX health check selects from the current allowed agents unless its plugin
config sets an explicit probeAgent.
First-run gotchas
First-run gotchas
- If
plugins.allowis set, it is a restrictive plugin inventory and must includeacpx, or the installed ACP backend is intentionally blocked (/acp doctorreports the missing allowlist entry). - The Codex ACP adapter ships with the
acpxplugin and launches locally when possible. - Codex ACP runs with an isolated
CODEX_HOME. OpenClaw copies trusted project trust entries plus safe model/provider routing config (model,model_provider,model_reasoning_effort,sandbox_mode, and safemodel_providers.<name>fields) from the host Codex config; auth, notifications, and hooks stay on the host config only. - Other target harness adapters may be fetched on demand with
npxon first use. - Vendor auth must already exist on the host for that harness.
- If the host has no npm or network access, first-run adapter fetches fail until caches are pre-warmed or the adapter is installed another way.
Runtime prerequisites
Runtime prerequisites
ACP launches a real external harness process. OpenClaw owns routing,
background-task state, delivery, bindings, and policy; the harness owns
its provider login, model catalog, filesystem behavior, and native tools.Before blaming OpenClaw, verify:
/acp doctorreports an enabled, healthy backend.- The target id is allowed by
acp.allowedAgentswhen that allowlist is set. - The harness command can start on the Gateway host.
- Provider auth is present for that harness (
claude,codex,gemini,opencode,droid, etc.). - The selected model exists for that harness - model ids are not portable across harnesses.
- The requested
cwdexists and is accessible, or omitcwdand let the backend use its default. - Permission mode matches the work. Non-interactive sessions cannot click native permission prompts, so write/exec-heavy coding runs usually need an ACPX permission profile that can proceed headlessly.
Supported harness targets
With theacpx backend, use these ids as /acp spawn <id> or
sessions_spawn({ runtime: "acp", agentId: "<id>" }) targets:
pi (pi-acp) is also registered in the acpx backend but is not a coding
harness in the same sense as the others above.
Custom acpx agent aliases can be configured in acpx itself, but OpenClaw
policy still checks acp.allowedAgents and any
agents.entries.*.runtime.acp.agent mapping before dispatch.