Quais arquivos o Claude Code não deveria ler no seu projeto?

Fala aí, beleza? Seu diretório de projeto quase nunca guarda só código

Tem o <code>.env</code> que você criou às pressas, tem aquele dump de banco que alguém baixou pra debugar um bug em produção, tem a planilha que o cliente mandou por e-mail e foi parar na raiz, tem chave de API em arquivo de configuração local

Aí você abre um agente ali dentro e ele passa a enxergar tudo isso como se fosse mais um arquivo do repo

E é por isso que rodar agente em pasta de projeto é uma decisão que vem ANTES do primeiro prompt: você precisa saber o que ele pode abrir

Neste post eu vou por partes: primeiro o critério pra separar o que é código do que é dado sensível, depois o mecanismo oficial de bloqueio do Claude Code (que é o <code>permissions.deny</code> nos settings, e não o <code>.claudeignore</code> que todo mundo repete por aí), e por fim os casos documentados em que o bloqueio já falhou

Quais arquivos costumam estar no projeto e não deveriam ser lidos

Antes de escrever regra nenhuma, o exercício é de inventário

A maioria dos vazamentos bobos não acontece porque a ferramenta é maligna, acontece porque ninguém lembrava que aquele arquivo estava lá

Variáveis de ambiente e chaves de API:

É o suspeito número um

Arquivo de variável de ambiente existe justamente pra separar segredo do código, então por definição o conteúdo dele não é instrução: é credencial viva

O exemplo que a própria documentação de permissões do Claude Code usa pra mostrar uma regra de bloqueio é exatamente o <code>.env</code>, o que já diz bastante sobre a frequência do problema

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Credenciais e certificados:

Chave privada, certificado, token de serviço, arquivo de credencial de cloud que você gerou pra testar deploy

Esses arquivos costumam ser gerados fora do fluxo do time e ficam esquecidos em subpasta

Nenhum deles ensina nada sobre a arquitetura do seu sistema, eles só abrem porta

Dumps e backups de banco:

O clássico: alguém precisava reproduzir um bug, puxou um dump e deixou na raiz do projeto

Dump não é schema

Schema é código (descreve estrutura), dump é o conteúdo das tabelas com dado real de gente real dentro

Exports de dados de usuário:

CSV de clientes, planilha de faturamento, JSON exportado de produção pra conferir um formato

Se o arquivo só existe porque alguém rodou uma query em produção, ele é dado, e ponto

Fixtures com dado real:

Esse é o mais traiçoeiro, porque VESTE roupa de código

Fixture de teste deveria ser dado fabricado, mas na prática muita gente popula fixture com um recorte de produção porque era mais rápido

Tome cuidado! O arquivo está na pasta de testes, versionado, com cara de código, e carrega e-mail e telefone de pessoa de verdade

Logs que carregam payload:

Log de aplicação que grava corpo de requisição vira depósito de token, header de autenticação e dado pessoal

O arquivo é gerado pela máquina, mas o conteúdo é o que passou por ela

A régua de decisão:

Se você quiser uma régua única pra aplicar em qualquer arquivo duvidoso, é essa:

o que é instrução para a máquina é código, o que só existe porque produção rodou ou o que identifica uma pessoa é dado

Repare na última linha, ela importa tanto quanto as outras

Bloquear demais também tem custo: o agente que não enxerga o schema passa a responder no chute, e aí você cai naquele problema chato de não saber se ele leu o projeto ou inventou a resposta

O objetivo não é cegar o agente, é escolher o que ele vê

Como bloquear a leitura desses arquivos no Claude Code

Com o inventário na mão, a parte mecânica é curta

O mecanismo oficial é o campo <code>permissions.deny</code> nos arquivos de settings, com regras do tipo <code>Read()</code> e <code>Edit()</code>

1. Escolha o escopo primeiro

São dois lugares possíveis: <code>.claude/settings.json</code> na raiz do projeto, ou <code>~/.claude/settings.json</code> no seu usuário

Projeto é pra regra que vale pra todo mundo que abrir aquele repo

Usuário é pra regra que vale pra você em QUALQUER projeto, e é aí que mora a sua rede de segurança pessoal

O erro comum deste passo: copiar o arquivo de settings de outro projeto sem entender o escopo dele, o mesmo tipo de armadilha de quando uma skill copiada de outro projeto simplesmente não pega

2. Escreva a regra deny

O formato é esse, direto da documentação:

<pre><code>{ "permissions": { "deny": ["Read(.env)"] } } </code></pre>

Se você também quer impedir escrita naquele caminho, a regra irmã é <code>Edit()</code>

3. Use a sintaxe de padrões do gitignore

As regras <code>Read</code> e <code>Edit</code> seguem a sintaxe de padrões do gitignore

Ou seja: <code>*</code> casa dentro de um único segmento de caminho, e <code>**</code> atravessa diretórios

Se você conhece a lógica de escrever <code>.gitignore</code>, já sabe escrever isso, é a mesma cabeça

O erro comum deste passo: escrever um padrão com um asterisco só achando que ele desce a árvore inteira, quando na verdade ele para no primeiro segmento

4. Entenda a ordem de avaliação

A ordem é fixa: deny, depois ask, depois allow

E a primeira correspondência decide, sem levar em conta especificidade

O erro comum deste passo (e é o mais caro): supor que uma regra mais específica ganha da mais genérica, como acontece em CSS ou em firewall

Não ganha

Quem chegou primeiro na ordem decide, então uma regra genérica no bloco errado pode atropelar a sua exceção caprichada

5. Saiba quem vence entre escopos

Um <code>deny</code> definido no escopo de usuário bloqueia um <code>allow</code> definido no escopo de projeto

O motivo é o passo anterior: deny de qualquer escopo é avaliado antes de allow

Na prática isso é ótimo, porque significa que a sua lista pessoal de bloqueios não pode ser desfeita por um settings de repo que você clonou hoje de manhã

6. Cuidado com a barra inicial

Uma barra inicial única em um padrão ancora na origem do arquivo de settings, e não na raiz do sistema de arquivos

Então <code>/Users/alice/file</code> não é o caminho absoluto que você imagina

Pra caminho absoluto de verdade, a barra é dupla: <code>//Users/alice/file</code>

O erro comum deste passo é justamente esse, e ele é silencioso: a regra existe, parece certa, e não casa com nada

7. Gerencie pela sessão com <code>/permissions</code>

O comando <code>/permissions</code> serve pra definir e gerenciar as regras de aprovação dentro da sessão do Claude Code

É o caminho mais rápido pra conferir o que está valendo agora sem ficar caçando arquivo

8. Não confunda <code>additionalDirectories</code> com configuração

Diretórios listados em <code>permissions.additionalDirectories</code> concedem apenas acesso a arquivos e não carregam nenhuma configuração daquele diretório

E tem um detalhe que pega muita gente: entradas de <code>allow</code> e de <code>additionalDirectories</code> em settings de projeto só passam a valer depois que você aceita o diálogo de confiança do workspace

O erro comum deste passo: apontar um diretório extra esperando que as regras dele viajem junto, e depois não entender por que nada foi aplicado antes do aceite

Quando as regras deny não bastam: sandbox no nível do sistema

Agora a parte que o pessoal costuma descobrir tarde

As regras <code>deny</code> de <code>Read</code> e <code>Edit</code> valem para as ferramentas de arquivo embutidas do Claude e para comandos de arquivo que o Claude Code reconhece no Bash

Isso cobre <code>cat</code>, <code>head</code>, <code>tail</code> e <code>sed</code>

Mas NÃO cobre um script Python ou Node que abre o arquivo por conta própria

Faz sentido quando você para pra pensar: a regra atua na camada da ferramenta, e um subprocesso arbitrário não pede licença pra ferramenta nenhuma, ele fala direto com o sistema operacional

Pra enforcement no nível do sistema operacional, que bloqueia todos os processos de acessar um caminho, a documentação orienta habilitar o sandbox

É uma camada ACIMA das regras de permissão, não um substituto delas

1. Habilite pelo <code>/sandbox</code>

O sandbox é embutido no Claude Code e configurado pelo comando <code>/sandbox</code>

Ele roda em macOS, Linux e WSL2, e trabalha com dois limites: isolamento de filesystem e isolamento de rede

2. No Linux e no WSL2, instale as dependências externas

Nesses dois ambientes o sandbox depende de dois pacotes: <code>bubblewrap</code>, responsável pelo isolamento de filesystem, e <code>socat</code>, responsável pelo relay de rede pelo proxy do sandbox

O erro comum deste passo é tentar habilitar o sandbox sem eles e achar que a funcionalidade está quebrada

3. Ajuste caminhos permitidos e negados

Dá pra definir caminhos permitidos e negados customizados, então o sandbox não é um botão de tudo ou nada

4. Desligue só o que atrapalha

Dá pra desligar apenas o isolamento de filesystem mantendo o isolamento de rede, via <code>sandbox.filesystem.disabled</code>

Útil quando o seu fluxo precisa escrever à vontade em disco, mas você quer manter o controle do que sai pela rede

E tem um efeito colateral bom nisso tudo: segundo a Anthropic, o sandboxing gerou uma redução de 84% nos prompts de permissão no uso interno da empresa

Ou seja, além de segurar melhor, ele para de te interromper a cada dois minutos, o que é meio o sonho de quem trabalha com agente o dia inteiro

E o que sai da sua máquina?

Já que estamos falando de dado sensível, vale fechar o quadro

O transcript da sessão fica armazenado em servidores da Anthropic enquanto conectado, pra sincronizar a conversa entre dispositivos

O tráfego vai por TLS, e a execução de código e o acesso a arquivos permanecem locais

A telemetria operacional não inclui código nem caminhos de arquivo

E o <code>/feedback</code> envia uma cópia do histórico de conversa, incluindo código, para a Anthropic: você escolhe quanto histórico incluir antes de enviar, entre só a sessão atual (o padrão), ou também outras sessões do mesmo projeto nas últimas 24 horas ou nos últimos 7 dias

Detalhe pequeno, consequência grande: mandar feedback num projeto com dado sensível aberto é uma decisão, não um clique automático

Bloqueios que já falharam (e o que fazer a respeito)

Aqui entra o motivo de eu ter dito lá no começo pra você não confiar no <code>.claudeignore</code>

Bloqueio de leitura é software, e software tem histórico

São três casos documentados que vale conhecer

Sintoma: o arquivo estava no <code>.claudeignore</code> e foi lido do mesmo jeito

Causa: em teste publicado pelo The Register em 28/01/2026, o Claude Code leu arquivos de segredo mesmo com a entrada correspondente em um arquivo <code>.claudeignore</code>, e a própria ferramenta tinha recomendado o <code>.claudeignore</code> como forma de bloqueio

A reportagem afirma que a Anthropic não respondeu ao pedido de comentário

No repositório oficial existe a issue #56997, cujo título diz, em inglês, que o <code>.claudeignore</code> é silenciosamente ignorado

Solução: migre a regra pro <code>permissions.deny</code>

O mecanismo descrito na documentação de permissões é esse, e é nele que você deve apostar

Silencioso é o pior tipo de falha de bloqueio, porque tu segue trabalhando achando que está coberto

Sintoma: o deny existia, mas foi contornado por link simbólico

Causa: a falha foi registrada como CVE-2026-25724, com classificação CWE-61 (symlink following)

Afetava versões anteriores à 2.1.7 e foi corrigida na 2.1.7

Solução: hoje o comportamento documentado é outro: quando o Claude acessa um symlink, as regras de permissão checam dois caminhos, o do próprio link e o do arquivo resolvido

E o tratamento difere: regras <code>allow</code> caem pra prompt ao usuário, e regras <code>deny</code> bloqueiam direto

Sintoma: o deny simplesmente parava de valer em comando muito longo

Causa: as regras <code>deny</code> deixavam de ser aplicadas quando um comando passava de 50 subcomandos

O caso foi divulgado pela Adversa AI em 01/04/2026 e corrigido pela Anthropic em 06/04/2026, na versão 2.1.90

Solução: manter a versão em dia, e não por hábito de organizado, por consequência prática mesmo

Dois dos três casos acima se resolvem só de estar atualizado

Na data de publicação deste post, a versão mais recente do Claude Code é a 2.1.237, de 20/08/2026 (a 2.1.234 é de 17/08/2026)

E a lição que sobra dos três juntos é a mesma: trate a regra de permissão como UMA camada, não como a única

Dado que não pode vazar não deveria estar dentro do diretório onde você abre o agente, com regra ou sem regra

Conclusão

A ordem de decisão é essa, e ela é curta

Primeiro inventariar: passar o olho no diretório e separar o que é instrução pra máquina do que é dado de produção ou de pessoa

Depois escrever o <code>deny</code> no escopo certo, lembrando que a ordem é deny, ask, allow, que a primeira correspondência decide sem especificidade, e que o <code>deny</code> de usuário prevalece sobre o <code>allow</code> de projeto

E subir pro sandbox quando tiver script rodando por fora das ferramentas de arquivo, porque é ali que a regra de permissão deixa de alcançar

Seu próximo passo é bem concreto: abre o projeto que você vai usar amanhã e lista os arquivos sensíveis que estão lá dentro agora

Essa lista vira regra <code>deny</code> hoje, antes da próxima sessão, não depois do primeiro susto 🙂

até o próximo post!