- Como usar com segurança a flag
--dangerously-skip-permissions do Claude Code
- Após avaliar vários ambientes de execução isolados, como Docker, VM e Firejail, concluiu-se que uma máquina virtual (VM) baseada em Vagrant era a opção mais adequada
- Com o Vagrant, foi possível manter isolamento completo via VM, configuração reproduzível e compartilhamento de pastas locais, evitando ao mesmo tempo os problemas de Docker-in-Docker
- O Claude Code foi configurado para manipular livremente o sistema com privilégios de sudo dentro da VM, executando na prática tarefas como rodar web apps, configurar banco de dados e automatizar testes
- Esse método é eficaz para evitar danos acidentais ao sistema de arquivos e, quando necessário, permite redefinir o ambiente com segurança ao excluir e recriar a VM
Contexto
- Ao usar o Claude Code, havia o incômodo de ter que confirmar solicitações de permissão a todo momento, então foi testado o uso da flag
--dangerously-skip-permissions
- Essa flag faz com que todas as ações, como instalação de pacotes, alteração de configurações e exclusão de arquivos, sejam executadas automaticamente sem aprovação prévia
- Isso evita interrupções no fluxo de trabalho e melhora a eficiência, mas traz risco de danificar o sistema de arquivos
- Para evitar isso, percebeu-se a necessidade de executar em um ambiente separado da conta do sistema operacional do host
Métodos considerados
- O primeiro caminho avaliado para isolamento foi o Docker, mas como o Claude precisa criar imagens Docker e executar contêineres, seria necessária uma configuração de Docker-in-Docker
- Nesse caso, o modo
--privileged seria exigido, o que anularia o propósito do sandbox
- Além disso, haveria aumento de complexidade e instabilidade por conta de problemas como aninhamento de rede e permissões de montagem de volumes
- Como outras alternativas, foram considerados os seguintes caminhos
- Execução em bare metal: há casos graves de dano relatados no Reddit, como exclusão de banco de dados ou do diretório home
sandbox-runtime: controle de acesso baseado em ACL, em que o Claude não consegue acessar nada além do código, mas com falta de liberdade total- Firejail: apresenta restrições semelhantes às do Docker
- Configuração manual de VM: baixa reprodutibilidade
- VM em nuvem: problemas de custo, latência e necessidade de enviar o código
Abordagem baseada em Vagrant
- Com o Vagrant, foi possível garantir isolamento completo por VM e configuração reproduzível
- Com pastas compartilhadas, o acesso funciona como se fosse local
- Não há problema de Docker-in-Docker e, se necessário, a VM pode ser facilmente excluída e recriada
- Durante o uso da versão 7.2.4 do VirtualBox, foi encontrado um bug de uso de CPU em 100%, e a causa foi confirmada por meio de uma issue no GitHub
- A configuração final do Vagrantfile tem as seguintes características
- Usa a imagem base
bento/ubuntu-24.04
- Aloca 4 GB de memória e 2 CPUs
- Instala Docker, Node.js, npm, git e unzip
- Instala globalmente
@anthropic-ai/claude-code
- Adiciona o usuário
vagrant ao grupo Docker
Forma de uso na prática
- No diretório do projeto, a sequência é
vagrant up → vagrant ssh → claude --dangerously-skip-permissions
- Na primeira inicialização, o provisionamento leva alguns minutos, e é necessário fazer login no Claude apenas uma vez por projeto
- Ao terminar o trabalho, é possível suspender a VM com
vagrant suspend
- Dentro da VM, o Claude recebe privilégios de sudo para executar tarefas como
- Rodar a API de uma web app e verificar com
curl
- Instalar um navegador, inspecionar manualmente o app e gerar testes E2E
- Configurar banco de dados PostgreSQL e testar migrações
- Criar e executar imagens Docker
- Graças a esse ambiente, o Claude consegue executar comandos, verificar saídas e conduzir processos iterativos por conta própria
Desempenho e segurança
- Em ambiente Linux + VirtualBox, há folga suficiente de recursos, sem atraso na sincronização de arquivos
- Itens que podem ser protegidos
- Danos acidentais ao sistema de arquivos
- Instalação indiscriminada de pacotes e alterações de configuração
- Itens que não podem ser protegidos
- Exclusão da pasta do projeto (sincronização bidirecional)
- Ataques que explorem vulnerabilidades de escape de VM
- Problemas em nível de rede
- Vazamento de dados (a VM tem acesso à internet)
- Essa configuração serve para prevenção de acidentes, e não para defesa contra ataques avançados
- Como o projeto usa Git, a recuperação é fácil mesmo em caso de dano; se necessário, é possível adotar sincronização unidirecional com
rsync para um isolamento mais rígido
Conclusão
- Depois de resolver o bug de CPU do VirtualBox, foi obtido um ambiente de execução sem atrito
- Agora é possível executar o Claude Code livremente dentro de um sandbox completo em VM
- Se houver problemas, basta excluir e recriar a VM, com reprodutibilidade garantida por um único Vagrantfile
- Ao usar a flag
--dangerously-skip-permissions, é fortemente recomendável montar um ambiente isolado como esse
1 comentários
Comentários do Hacker News
Ao usar o Claude, no fim você acaba apertando Enter depois de alguns meses por causa da fadiga de decisão
Por isso, sinto que é bem mais seguro rodar em modo YOLO, mas com um ambiente em sandbox já preparado
No Ubuntu 22.04, montei uma sandbox em camadas combinando bubblewrap e Landlock LSM
O Landlock restringe o acesso ao sistema de arquivos com base em whitelist e também controla o acesso a portas TCP
O bubblewrap separa os namespaces de montagem para criar um
/tmppor projeto e esconder chaves secretasCom o dnsmasq, configurei uma whitelist de DNS para que só os domínios necessários possam ser resolvidos
Graças a essa estrutura, diminuiu o estresse de ter que ficar monitorando o agente o tempo todo
Ficar aprovando um por um os trechos de elisp sugeridos pelo Claude foi uma experiência exaustiva
Mesmo tomando cuidado só para ele não instalar coisas aleatórias com comandos Bash, já foi bem desgastante
/sandboxAqui é o Srini, da Docker
Muita gente está usando Docker para tentar resolver esse problema, e também ouvimos bastante feedback sobre as limitações de Docker-in-Docker
Por isso, lançamos experimentalmente o Docker Sandboxes em preview
Ainda está no começo, mas estamos desenvolvendo a próxima versão com base em MicroVM para evitar os problemas de Docker-in-Docker
Quero entender se o Claude consegue subir outros contêineres sem privilégios dentro do Docker Sandbox
Parece que a maioria quer evitar rodar uma VM local por conta própria, mas não entendo por quê
Na prática, uma VM local é a opção mais simples e resolve tudo
Se você usa Docker no Mac, já está rodando em cima de uma VM Linux, então na prática está só um nível distante do ambiente real
Também dá para acessar direto por SSH da IDE e inspecionar o código
Eu ligo a opção
--dangerously-skip-permissionse trato toda alteração via PRJunto com workmux, venho usando isso há meses, e é muito eficiente para tocar vários PRs ao mesmo tempo
A vantagem sobre VM na nuvem é que subir vários contêineres ao mesmo tempo consome muita memória
Se você deixar uma VM robusta na nuvem rodando 24/7, o custo fica alto demais
Mesmo sem explorar uma vulnerabilidade de escape de VM, uma IA maliciosa pode conseguir acesso ao host adicionando código arbitrário ao Vagrantfile
Mesmo que a preocupação seja só com erros acidentais, se o Claude mexer nos hooks de commit isso pode causar problema quando eles forem executados
Dá para sentir como é realmente difícil manter isolamento completo sem perder praticidade no desenvolvimento
Por exemplo, usando volume mount do Docker para permitir alterações só na pasta
sandbox/e bloquear acesso ao.gitEu trabalho tirando snapshot, subindo uma VM pequena para rodar o agente e depois comparando os snapshots
Nunca faço sincronização automática, porque isso destrói o objetivo do isolamento
Estou tentando outra abordagem — interceptar o que o Claude tenta executar
O Shannot captura a intenção antes da execução e intercepta chamadas de sistema dentro de uma sandbox PyPy
Comandos e escritas em arquivos ficam só no log e não são executados de verdade
Só depois que o usuário revisa e aprova na TUI é que a execução acontece
A diferença para uma VM é que, enquanto a VM deixa tudo rodar livremente num ambiente totalmente isolado, o Shannot aplica mudanças no sistema real com aprovação humana
É adequado para tarefas como modificar servidores
Também tem integração com Claude MCP, execução remota via SSH e checkpoint/rollback
No fim, ela para na primeira solicitação de aprovação, então o agente não consegue explorar livremente
O que eu quero é que o agente tente tudo até o fim sem parar no meio e só depois eu avalie o resultado
Aí sim a economia de tempo é grande
Lembra o modo de extensão de sistema nativo para Mac do Leash, mas ainda não tem um modo de aprovação interativa completo
Projeto interessante
Quando a fadiga de aprovação acumula, dá vontade de usar
--dangerously-skip-permissionsEntão eu rodo o Claude Code dentro de um devcontainer
O acesso a arquivos fica limitado ao repositório e a rede só permite whitelist
Depois generalizei isso com docker compose e o próximo passo é adicionar suporte a outros agentes como Codex e OpenCode
Quero forçar o roteamento da rede por um proxy no host para reforçar logging e controle
Por enquanto estou quebrando o galho com iptables
Ainda está no começo, mas já funciona muito bem
Código: agent-sandbox
Estou usando mitmproxy como proxy de rede; ainda não está perfeito, mas está quase lá
O Claude passou horas configurando o sistema sozinho e terminou o app
Não escrevemos uma linha de código e o resultado ficou surpreendentemente bom
A velocidade do desenvolvimento com IA é realmente impressionante
Minha solução é simples
Assim, o comando npx roda de forma transparente dentro de uma sandbox Bubblewrap, expondo só o diretório atual
Dá para implementar isso com algumas linhas de shell POSIX puro
sandbox-run
Outra desvantagem é que, depois que você reduz os privilégios, não dá para restaurá-los
Eu simplesmente coloco tudo num contêiner LXC sem privilégios e pronto
Meu modelo de ameaça não é um ataque sofisticado, e sim a possibilidade de “apagar sem querer meu diretório home”
Eu deixo scripts utilitários no diretório
run/do projeto e subo os contêineres com base em composeO devcontainer fica mapeado com diretórios e volumes do host
O Claude lida bem com configuração de serviços, atualização de scripts e diagnóstico de problemas de runtime
Não há integração com navegador, mas com Playwright ou Puppeteer provavelmente já dá para fazer tudo de que precisa
Queria saber a opinião do pessoal sobre o sandboxing embutido do Claude Code
Link da documentação oficial
O Claude Code tem uma escape hatch que permite desativar a sandbox quando necessário
Se um comando falhar por causa das restrições da sandbox, o Claude pode analisar o motivo e tentar de novo com
dangerouslyDisableSandboxO fato de o agente poder desativar a sandbox por conta própria parece uma vulnerabilidade; queria saber se nesse caso existe algum processo de aprovação pelo usuário
Issues relacionadas: #14268, #13583, #10089