Sandboxing & Isolation

.md

Sandboxing & Isolation

Untrusted agent code is executed inside an isolated Docker container (Dockerfile.sandbox with WITH_SANDBOX=1).

Security Controls

Blocked shell deny patterns (e.g. curl | sh, fork bombs, reverse shells).
Host exec denies commands that name the gateway data dir. A tenant agent’s run may still use its own tenant directory (for example its skills store), and a command that names another tenant’s directory is denied. Master-tenant runs get no tenant directory. Subagents and native workers use the same exec and the same rules. This check matches path text, so it is a guard, not an isolation boundary.
On Linux with Landlock (kernel 6.2 or later, including inside Docker with the default seccomp profile), host exec for a tenant agent also runs under a kernel filesystem policy: it can reach only its own tenant data and workspace directories (which hold its team workspace and uploads), plus the shared runtime packages and the system skills of the shared skills store, read-only. Packages a tenant agent installs (pip install, npm install -g) go to a runtime directory inside its own tenant data directory and are visible to that tenant only. Other tenants’ files, the main workspace, the gateway database and the config file fail with Permission denied, whatever the command does (cd .., symlinks, scripts). The command also cannot read the environment, memory or open files of the gateway, MCP servers or other tenants’ commands under /proc, even when the gateway runs as root. A confined command also cannot list or create entries directly in the parent directories of those paths, such as ls /, or $HOME when the data dir lives there. The policy covers file contents, not metadata or signals: use the sandbox when tenants must not affect each other at all.
Where Landlock is not available, the gateway logs security.exec_fs_confinement_unavailable and tenant runs cannot use their tenant directory from host exec. Enable the Docker sandbox for exec in multi-tenant deployments on such hosts: a command that runs in the sandbox keeps its own tenant directory, mounted read-only. If the sandbox is disabled for a call on such a host, a command that names the tenant directory is refused instead of running on the host.
tools.exec.tenant_host_policy (env GOCLAW_EXEC_TENANT_HOST_POLICY) decides whether tenant agents may run exec on the host: deny refuses it, warn (the default in this release) runs it and logs security.exec_tenant_host_would_deny, and allow runs it with the operator accepting that tenant agents can read other tenants’ files, the gateway token and same-uid process env. Under deny, credentialed CLIs that tenant runs would start on the host are refused too. For multi-tenant installs, enable the Docker sandbox and set deny. Master-tenant runs are not affected. ACP terminals and the Claude CLI built-in Bash run outside exec and are not covered by this setting.
Claude CLI agents run exec through the MCP bridge. On the host, bridge exec never gets the tenant directory. In the Docker sandbox it does: the container mounts the agent’s own tenant directory read-only at the same path, so its skill scripts run, while no other tenant’s directory exists in the container. If the sandbox is disabled for the call, bridge exec fails instead of running on the host.
Timeouts on all subshell processes (default 60s).
Isolated virtual filesystem boundaries.