#Can ACP runtime sessions be sandboxed, or is host isolation the intended model?

1 messages · Page 1 of 1 (latest)

obsidian kite
#

I’m experimenting with an OpenClaw agent that delegates work to Codex through ACP:

sessions_spawn({
  runtime: "acp",
  agentId: "codex",
  mode: "run",
  task: "..."
})
From the docs, it looks like ACP sessions run host-side and sandbox: "require" is unsupported for runtime: "acp". So a sandboxed OpenClaw agent cannot spawn a Codex/ACP worker with the same OpenClaw sandbox guarantees.

Is there any supported or recommended way to run ACP harness sessions with stronger isolation? For example:

running acpx inside a container
using a separate low-privilege OS user
binding ACP to a locked-down workspace
another recommended isolation pattern
Or is the intended model simply: ACP is host-runtime work, and if we need hard sandboxing we should use native OpenClaw subagents instead?
pseudo vergeBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

warped shoreBOT
#

Simon — your read is right.

Current model: ACP/acpx is a host-runtime integration, not an OpenClaw-sandboxed runtime. OpenClaw explicitly documents:

  • sandboxed requester sessions cannot spawn ACP sessions
  • sessions_spawn({ runtime: "acp", sandbox: "require" }) is unsupported
  • OpenClaw’s sandbox policy does not wrap the external harness process

So if you need OpenClaw-enforced sandboxing, use native runtime: "subagent" with agents.*.sandbox instead.

For ACP, the supported mitigations are more like deployment isolation, not OpenClaw sandbox guarantees:

  • run the whole Gateway/acpx environment under a low-privilege OS user / VM / container
  • restrict the ACP cwd to a dedicated repo/workspace
  • use ACP allowlists like acp.allowedAgents
  • tune acpx/harness permission mode carefully
  • prefer separate OpenClaw agents/workspaces/auth stores for blast-radius separation