Two backends, one interface
local (default) runs /bin/sh -c in the host process for the legacy behaviour. docker ("shell_backend": "docker" in config.json or --backend docker per-run) routes every shell call through a container instead.
// Shell backends
PasClaw factors shell execution behind an IShellBackend interface so operators can choose where commands actually run. The docker backend spawns a per-session container at session start, docker execs every shell_exec and execute_code call into it, and tears it down at session end — escapes from the denylist can only touch the container, not the host.
local (default) runs /bin/sh -c in the host process for the legacy behaviour. docker ("shell_backend": "docker" in config.json or --backend docker per-run) routes every shell call through a container instead.
The workspace is bind-mounted at the same path inside the container as on the host. fs_* tools on the host and cat/tee inside the container reference the exact same files with no path translation.
~/.pasclaw/config.json is deliberately not mounted into the container, so even a fully compromised shell cannot read provider credentials from inside the sandbox.
Phase 1 wires the docker backend into pasclaw agent (interactive and one-shot) and pasclaw heartbeat, so the highest-risk surfaces benefit first.
From the documentation
Implementation notes drawn from the PasClaw repository documentation.
The docker backend spawns one container per session, docker execs every shell call into it, and stops it at session end.
Choose the backend statically or per invocation.
// config.json
"shell_backend": "docker"
// per-run
pasclaw agent --backend dockerCommon questions
Keep exploring
See how the rest of PasClaw fits together.