-
-
Notifications
You must be signed in to change notification settings - Fork 53k
Description
Feature: Pluggable sandbox backends & per-agent exec routing
Problem
Currently, OpenClaw sandboxing is Docker-only (sandbox.docker.image), and tools.exec.host is a global setting — all agents share the same exec target. This creates two gaps:
1. No pluggable sandbox backends
The only sandbox option is Docker containers. For coding agents that need full system access (npm, git, gh, native compilation), Docker is too restrictive. Users are already working around this with:
- OrbStack VMs connected as OpenClaw nodes
- exe.dev cloud VMs (SSH-based)
- Direct
orb runorchestration bypassing the sandbox layer
2. No per-agent exec routing
tools.exec.host is global — you can't say "coding-agent execs on a VM node, main agent execs on the host." It's all-or-nothing.
Proposed Solution
Pluggable sandbox backends
Allow sandbox.mode to support additional backends beyond Docker:
Per-agent tools.exec.host
Allow each agent to specify its own exec target:
{
"id": "coding-agent",
"tools": {
"exec": {
"host": "node",
"node": "Coding VM" // route to a specific paired node
}
}
}This would let configurations like:
main→ exec on host (no sandbox)reader-agent→ exec in Docker (restrictive)coding-agent→ exec on OrbStack VM node (full tooling)
Context
This came up while setting up an OrbStack VM as an OpenClaw node for a coding agent. The node pattern works (VM runs openclaw node run, connects via WebSocket, appears as a paired node), but there's no way to route a specific agent's exec calls to that node automatically. The workaround is manual orb run orchestration or telling the agent to use host=node in its system prompt.
Related: Brad Fitzpatrick (crawshaw) recommends VMs over Docker for agent sandboxing — "You have to turn off the sandbox... use a fresh VM." exe.dev is built on this premise with exe.new/openclaw as a documented use case.
Environment
- macOS (Apple Silicon)
- OpenClaw 2026.2.6-3
- OrbStack VM connected as paired node