1

Sobre o Read não pegar script que abre o arquivo sozinho: o Claude Code tem um sandbox pro Bash (/sandbox na sessão, ou sandbox.enabled no settings.json) que fecha esse buraco no nível do sistema. Ele vale pro comando e pros processos que o comando abre, então um python lendo o .env também bate na parede se o caminho estiver no filesystem.denyRead. Só que por padrão ele deixa ler quase tudo, inclusive o ~/.ssh, então tem que listar o que fica de fora.

O Bash(git push *) também tem furo. A própria doc avisa que deny de Bash não pega o programa chamado pelo caminho completo nem dentro de sh -c. Pra push eu confiaria mais em não deixar credencial com permissão de escrita dentro do container.

Carregando publicação patrocinada...
1

Valeu demais, @plugandship! Fui conferir na documentação e você tem razão nos dois pontos. O deny de Bash casa com o texto do comando, então /usr/bin/git push e sh -c escapam. E o deny de Read não segura um script que abre o arquivo sozinho. A frase do post que dizia que o push era “recusado sempre” estava errada.

Atualizei o post aqui e no blog com uma seção nova, com crédito pra você. Ela fala do sandbox com denyRead listando ~/.ssh, .env e companhia, já que por padrão ele deixa ler quase tudo. Também incluí dois detalhes que achei na documentação: o allowUnsandboxedCommands: false, pro Claude não tentar rodar o comando fora do sandbox quando ele falha, e a rede do sandbox, que só libera os domínios permitidos.

E fiquei com a sua conclusão sobre o push: regra pode ter furo, credencial que não existe, não. Valeu por melhorar o post!