O Verboo Code pode rodar os comandos Bash que o próprio agente decide executar dentro de um sandbox isolado do sistema operacional, sem acesso de rede fora de uma lista permitida e sem escrever fora das pastas liberadas. O recurso já vem na CLI, mas desligado por padrão, e a maioria de quem usa a Verboo Code no dia a dia nunca digitou o comando que liga isso: /sandbox.
Como ativar o sandbox de comandos no Verboo Code?
Adicione sandbox.enabled: true nas suas configurações de usuário (nunca no arquivo de configuração do projeto, veja o motivo mais abaixo). A partir daí, o Bash e outras ferramentas que tocam o sistema de arquivos ou a rede tentam rodar dentro do sandbox antes de pedir confirmação.
{
"sandbox": {
"enabled": true
}
}
O sandbox funciona em macOS, Linux e WSL2. WSL1 não é suportado. No Linux e no WSL2 você também precisa instalar duas dependências:
sudo apt install bubblewrap socatSem elas, a Verboo Code não finge que sandboxou o comando: ela avisa que a dependência está faltando e diz o que instalar.
Por que não dá para ligar isso no settings.json do projeto?
Porque é justamente o arquivo que um repositório não confiável poderia trazer pronto. A flag sandbox.enabled só é lida das suas configurações de usuário ou das configurações locais (não versionadas), nunca do arquivo de configuração que vem dentro do próprio projeto. Um repositório malicioso não consegue desligar o seu sandbox, nem fingir que ligou um que não existe, só editando um arquivo que você vai clonar.
O que aparece quando eu rodo /sandbox?
Um menu com 4 abas, o suficiente para configurar e diagnosticar o sandbox sem editar JSON na mão:
| Aba | O que mostra |
|---|---|
| Mode | o modo atual (Auto-allow ou desligado) e a opção de trocar |
| Overrides | os comandos que você já marcou para sempre rodar fora do sandbox |
| Config | domínios de rede liberados e outras opções finas |
| Dependencies | o que falta instalar no seu sistema, se faltar algo |
O que muda na aprovação de comandos com o sandbox ligado?
No modo Auto-allow, um comando tenta rodar dentro do sandbox automaticamente, sem parar para perguntar. Se ele não puder ser sandboxado por algum motivo, cai de volta para o fluxo normal de permissão, com a pergunta de sempre. Regras explícitas de ask ou deny que você já configurou continuam valendo em qualquer um dos dois casos.
Isso muda quem decide se o comando roda. Sem sandbox, é você que aprova cada Bash antes de ele executar. Com o Auto-allow ligado, quem aprova é o próprio limite do sandbox: se o comando está contido, ele roda direto. Isso só protege o que a configuração realmente restringe. Um comando com acesso liberado a um domínio sensível em allowedDomains, por exemplo, continua tendo acesso a esse domínio de dentro do sandbox. Vale revisar essa lista antes de contar com o Auto-allow para tudo.
Como restringir rede e abrir uma exceção pontual?
Para limitar a que domínios um comando sandboxado pode se conectar, use network.allowedDomains:
{
"sandbox": {
"enabled": true,
"network": {
"allowedDomains": ["registry.npmjs.org", "github.com"]
}
}
}
Para o caminho contrário, um comando específico que precisa rodar fora do sandbox, use /sandbox exclude direto na sessão:
/sandbox exclude "npm run test:*"Isso grava o padrão nas suas configurações locais do projeto (o arquivo que não é versionado), e esse comando passa a rodar fora do sandbox sem precisar confirmar de novo a cada vez.
Rodar um agente que executa comando sozinho já é uma troca de controle por velocidade. O sandbox não elimina essa troca, mas muda o tamanho do dano possível: em vez de confiar só na revisão humana de cada linha, existe uma segunda barreira no nível do sistema operacional. Se você já deixa a Verboo Code rodar comandos sem confirmar cada um, essa é a configuração que fecha essa porta sem tirar a velocidade do agente.
