agents.defaults.sandbox ou agents.list[].sandbox). Se o sandbox estiver desativado, as ferramentas rodam no host. O Gateway permanece no host; a execução de ferramentas roda em um sandbox isolado quando habilitada.
Este não é um limite de segurança perfeito, mas limita materialmente o acesso ao sistema de arquivos e a processos quando o modelo faz algo inadequado.
O que entra em sandbox
- Execução de ferramentas (
exec,read,write,edit,apply_patch,process, etc.). - Navegador em sandbox opcional (
agents.defaults.sandbox.browser).
- O próprio processo do Gateway.
- Qualquer ferramenta explicitamente autorizada a rodar fora do sandbox (por exemplo,
tools.elevated).- Exec elevado ignora o sandbox e usa o caminho de escape configurado (
gatewaypor padrão, ounodequando o alvo do exec énode). - Se o sandbox estiver desativado,
tools.elevatednão altera a execução (já está no host). Consulte Modo Elevado.
- Exec elevado ignora o sandbox e usa o caminho de escape configurado (
Modos
agents.defaults.sandbox.mode controla quando o sandbox é usado:
- off
- non-main
- all
Sem sandbox.
Escopo
agents.defaults.sandbox.scope controla quantos contêineres são criados:
"agent"(padrão): um contêiner por agente."session": um contêiner por sessão."shared": um contêiner compartilhado por todas as sessões em sandbox.
Backend
agents.defaults.sandbox.backend controla qual runtime fornece o sandbox:
"docker"(padrão quando o sandbox está habilitado): runtime de sandbox local baseado em Docker."ssh": runtime de sandbox remoto genérico baseado em SSH."openshell": runtime de sandbox baseado no OpenShell.
agents.defaults.sandbox.ssh. A configuração específica do OpenShell fica em plugins.entries.openshell.config.
Escolhendo um backend
| Docker | SSH | OpenShell | |
|---|---|---|---|
| Onde roda | Contêiner local | Qualquer host acessível por SSH | Sandbox gerenciado pelo OpenShell |
| Configuração | scripts/sandbox-setup.sh | Chave SSH + host de destino | Plugin OpenShell habilitado |
| Modelo de workspace | Bind mount ou cópia | Canônico remoto (semeia uma vez) | mirror ou remote |
| Controle de rede | docker.network (padrão: none) | Depende do host remoto | Depende do OpenShell |
| Sandbox de navegador | Compatível | Não compatível | Ainda não compatível |
| Bind mounts | docker.binds | N/A | N/A |
| Melhor para | Desenvolvimento local, isolamento completo | Descarregar para uma máquina remota | Sandboxes remotos gerenciados com sincronização bidirecional opcional |
Backend Docker
O sandbox fica desativado por padrão. Se você habilitar o sandbox e não escolher um backend, o OpenClaw usa o backend Docker. Ele executa ferramentas e navegadores em sandbox localmente via socket do daemon Docker (/var/run/docker.sock). O isolamento do contêiner de sandbox é determinado pelos namespaces do Docker.
Para expor GPUs do host a sandboxes Docker, defina agents.defaults.sandbox.docker.gpus ou a substituição por agente agents.list[].sandbox.docker.gpus. O valor é passado para a flag --gpus do Docker como um argumento separado, por exemplo "all" ou "device=GPU-uuid", e exige um runtime de host compatível, como NVIDIA Container Toolkit.
Backend SSH
Usebackend: "ssh" quando você quiser que o OpenClaw coloque exec, ferramentas de arquivo e leituras de mídia em sandbox em uma máquina arbitrária acessível por SSH.
Como funciona
Como funciona
- O OpenClaw cria uma raiz remota por escopo em
sandbox.ssh.workspaceRoot. - No primeiro uso após criar ou recriar, o OpenClaw semeia esse workspace remoto a partir do workspace local uma vez.
- Depois disso,
exec,read,write,edit,apply_patch, leituras de mídia de prompt e staging de mídia de entrada rodam diretamente contra o workspace remoto via SSH. - O OpenClaw não sincroniza automaticamente alterações remotas de volta para o workspace local.
Material de autenticação
Material de autenticação
identityFile,certificateFile,knownHostsFile: usam arquivos locais existentes e os passam pela configuração do OpenSSH.identityData,certificateData,knownHostsData: usam strings inline ou SecretRefs. O OpenClaw os resolve por meio do snapshot normal do runtime de segredos, grava-os em arquivos temporários com0600e os exclui quando a sessão SSH termina.- Se tanto
*Filequanto*Dataestiverem definidos para o mesmo item,*Dataprevalece nessa sessão SSH.
Consequências do modelo canônico remoto
Consequências do modelo canônico remoto
Este é um modelo canônico remoto. O workspace SSH remoto se torna o estado real do sandbox após a semeadura inicial.
- Edições locais no host feitas fora do OpenClaw após a etapa de semeadura não ficam visíveis remotamente até você recriar o sandbox.
openclaw sandbox recreateexclui a raiz remota por escopo e semeia novamente a partir do local no próximo uso.- Sandbox de navegador não é compatível com o backend SSH.
- Configurações
sandbox.docker.*não se aplicam ao backend SSH.
Backend OpenShell
Usebackend: "openshell" quando você quiser que o OpenClaw coloque ferramentas em sandbox em um ambiente remoto gerenciado pelo OpenShell. Para o guia completo de configuração, a referência de configuração e a comparação de modos de workspace, consulte a página do OpenShell dedicada.
O OpenShell reutiliza o mesmo transporte SSH central e a mesma ponte de sistema de arquivos remoto do backend SSH genérico, e adiciona ciclo de vida específico do OpenShell (sandbox create/get/delete, sandbox ssh-config) mais o modo de workspace mirror opcional.
mirror(padrão): o workspace local permanece canônico. O OpenClaw sincroniza arquivos locais para o OpenShell antes do exec e sincroniza o workspace remoto de volta após o exec.remote: o workspace OpenShell é canônico depois que o sandbox é criado. O OpenClaw semeia o workspace remoto uma vez a partir do workspace local; em seguida, ferramentas de arquivo e exec rodam diretamente contra o sandbox remoto sem sincronizar alterações de volta.
Detalhes do transporte remoto
Detalhes do transporte remoto
- O OpenClaw solicita ao OpenShell a configuração SSH específica do sandbox via
openshell sandbox ssh-config <name>. - O core grava essa configuração SSH em um arquivo temporário, abre a sessão SSH e reutiliza a mesma ponte de sistema de arquivos remoto usada por
backend: "ssh". - No modo
mirror, apenas o ciclo de vida difere: sincroniza o local para o remoto antes do exec e depois sincroniza de volta após o exec.
Limitações atuais do OpenShell
Limitações atuais do OpenShell
- o navegador do sandbox ainda não é compatível
sandbox.docker.bindsnão é compatível no backend do OpenShell- controles de runtime específicos do Docker em
sandbox.docker.*ainda se aplicam apenas ao backend Docker
Modos de workspace
O OpenShell tem dois modelos de workspace. Esta é a parte que mais importa na prática.- mirror (local canônico)
- remote (OpenShell canônico)
Use
plugins.entries.openshell.config.mode: "mirror" quando quiser que o workspace local permaneça canônico.Comportamento:- Antes de
exec, o OpenClaw sincroniza o workspace local para o sandbox do OpenShell. - Após
exec, o OpenClaw sincroniza o workspace remoto de volta para o workspace local. - As ferramentas de arquivo ainda operam pela ponte do sandbox, mas o workspace local continua sendo a fonte da verdade entre turnos.
- você edita arquivos localmente fora do OpenClaw e quer que essas alterações apareçam no sandbox automaticamente
- você quer que o sandbox do OpenShell se comporte o mais parecido possível com o backend Docker
- você quer que o workspace do host reflita as gravações do sandbox após cada turno de exec
mirror se você pensa no sandbox como um ambiente de execução temporário. Escolha remote se você pensa no sandbox como o workspace real.
Ciclo de vida do OpenShell
Os sandboxes do OpenShell ainda são gerenciados pelo ciclo de vida normal de sandbox:openclaw sandbox listmostra runtimes do OpenShell e também runtimes Dockeropenclaw sandbox recreateexclui o runtime atual e permite que o OpenClaw o recrie no próximo uso- a lógica de prune também é ciente do backend
remote, recriar é especialmente importante:
- recriar exclui o workspace remoto canônico desse escopo
- o próximo uso inicializa um workspace remoto novo a partir do workspace local
mirror, recriar principalmente redefine o ambiente de execução remoto, porque o workspace local permanece canônico de qualquer forma.
Acesso ao workspace
agents.defaults.sandbox.workspaceAccess controla o que o sandbox pode ver:
- none (padrão)
- ro
- rw
As ferramentas veem um workspace de sandbox em
~/.openclaw/sandboxes.- o modo
mirrorainda usa o workspace local como a fonte canônica entre turnos de exec - o modo
remoteusa o workspace remoto do OpenShell como a fonte canônica após a inicialização inicial workspaceAccess: "ro"e"none"ainda restringem o comportamento de gravação da mesma forma
media/inbound/*).
Observação sobre Skills: a ferramenta
read é enraizada no sandbox. Com workspaceAccess: "none", o OpenClaw espelha Skills qualificadas para o workspace do sandbox (.../skills) para que possam ser lidas. Com "rw", Skills do workspace são legíveis em /workspace/skills, e Skills gerenciadas, empacotadas ou de Plugin qualificadas são materializadas no caminho somente leitura gerado /workspace/.openclaw/sandbox-skills/skills.Montagens bind personalizadas
agents.defaults.sandbox.docker.binds monta diretórios adicionais do host no contêiner. Formato: host:container:mode (por exemplo, "/home/user/source:/source:rw").
Binds globais e por agente são mesclados (não substituídos). Em scope: "shared", binds por agente são ignorados.
agents.defaults.sandbox.browser.binds monta diretórios adicionais do host apenas no contêiner do navegador do sandbox.
- Quando definido (incluindo
[]), ele substituiagents.defaults.sandbox.docker.bindspara o contêiner do navegador. - Quando omitido, o contêiner do navegador recorre a
agents.defaults.sandbox.docker.binds(compatível com versões anteriores).
Imagens e configuração
Imagem Docker padrão:openclaw-sandbox:bookworm-slim
Checkout de código-fonte vs npm installOs scripts auxiliares
scripts/sandbox-setup.sh, scripts/sandbox-common-setup.sh e scripts/sandbox-browser-setup.sh só estão disponíveis ao executar a partir de um checkout de código-fonte. Eles não estão incluídos no pacote npm.Se você instalou o OpenClaw via npm install -g openclaw, use os comandos docker build inline mostrados abaixo.Crie a imagem padrão
A partir de um checkout de código-fonte:A partir de uma instalação npm (sem necessidade de checkout de código-fonte):A imagem padrão não inclui Node. Se uma Skill precisar de Node (ou outros runtimes), inclua em uma imagem personalizada ou instale via
sandbox.docker.setupCommand (requer saída de rede + root gravável + usuário root).O OpenClaw não substitui silenciosamente por debian:bookworm-slim puro quando openclaw-sandbox:bookworm-slim está ausente. Execuções de sandbox que miram a imagem padrão falham rapidamente com uma instrução de build até que você a crie, porque a imagem empacotada carrega python3 para auxiliares de gravação/edição do sandbox.Opcional: crie a imagem comum
Para uma imagem de sandbox mais funcional com ferramentas comuns (por exemplo, A partir de uma instalação npm, crie a imagem padrão primeiro (veja acima) e depois crie a imagem comum sobre ela usando o
curl, jq, Node 24, pnpm, python3 e git):A partir de um checkout de código-fonte:scripts/docker/sandbox/Dockerfile.common do repositório.Depois defina agents.defaults.sandbox.docker.image como openclaw-sandbox-common:bookworm-slim.Opcional: crie a imagem do navegador do sandbox
A partir de um checkout de código-fonte:A partir de uma instalação npm, crie usando o
scripts/docker/sandbox/Dockerfile.browser do repositório.agents.defaults.sandbox.docker.network.
Padrões de segurança de rede
Padrões de segurança de rede
network: "host"é bloqueado.network: "container:<id>"é bloqueado por padrão (risco de bypass por ingresso no namespace).- Substituição de emergência:
agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true.
scripts/docker/setup.sh pode inicializar a configuração do sandbox. Defina OPENCLAW_SANDBOX=1 (ou true/yes/on) para habilitar esse caminho. Você pode substituir o local do socket com OPENCLAW_DOCKER_SOCKET. Configuração completa e referência de env: Docker.
setupCommand (configuração única do contêiner)
setupCommand é executado uma vez depois que o contêiner do sandbox é criado (não em toda execução). Ele é executado dentro do contêiner via sh -lc.
Caminhos:
- Global:
agents.defaults.sandbox.docker.setupCommand - Por agente:
agents.list[].sandbox.docker.setupCommand
Armadilhas comuns
Armadilhas comuns
- O
docker.networkpadrão é"none"(sem saída), então instalações de pacotes vão falhar. docker.network: "container:<id>"exigedangerouslyAllowContainerNamespaceJoin: truee deve ser usado apenas como substituição de emergência.readOnlyRoot: trueimpede gravações; definareadOnlyRoot: falseou crie uma imagem personalizada.userdeve ser root para instalações de pacotes (omitauserou definauser: "0:0").- Execução no sandbox não herda o
process.envdo host. Useagents.defaults.sandbox.docker.env(ou uma imagem personalizada) para chaves de API de Skills. - Valores em
agents.defaults.sandbox.docker.envsão passados como variáveis de ambiente explícitas do contêiner Docker. Qualquer pessoa com acesso ao daemon do Docker pode inspecioná-los com comandos de metadados do Docker, comodocker inspect. Use uma imagem personalizada, um arquivo de segredo montado ou outro caminho de entrega de segredos se essa exposição de metadados não for aceitável.
Política de ferramentas e rotas de escape
As políticas de permissão/bloqueio de ferramentas ainda se aplicam antes das regras de sandbox. Se uma ferramenta for negada globalmente ou por agente, o sandbox não a reabilita.tools.elevated é uma rota de escape explícita que executa exec fora do sandbox (gateway por padrão, ou node quando o alvo de exec é node). Diretivas /exec só se aplicam a remetentes autorizados e persistem por sessão; para desabilitar exec rigidamente, use uma política de negação de ferramenta (veja Sandbox vs Tool Policy vs Elevated).
Depuração:
- Use
openclaw sandbox explainpara inspecionar o modo de sandbox efetivo, a política de ferramentas e as chaves de configuração de correção. - Veja Sandbox vs Tool Policy vs Elevated para o modelo mental de “por que isto está bloqueado?”.
Substituições para vários agentes
Cada agente pode substituir sandbox + ferramentas:agents.list[].sandbox e agents.list[].tools (mais agents.list[].tools.sandbox.tools para a política de ferramentas do sandbox). Veja Multi-Agent Sandbox & Tools para a precedência.
Exemplo mínimo de habilitação
Relacionado
- Multi-Agent Sandbox & Tools — substituições por agente e precedência
- OpenShell — configuração de backend de sandbox gerenciado, modos de workspace e referência de configuração
- Configuração de sandbox
- Sandbox vs Tool Policy vs Elevated — depuração de “por que isto está bloqueado?”
- Segurança