Claude Code vaza o código do seu projeto? O que sai da sua máquina e o que dá para limitar

Fala aí, beleza? Existe uma cena que trava muito dev experiente: abrir o terminal dentro do repositório da empresa, aquele com NDA assinado por cima, e hesitar antes de apontar um agente pra lá

O medo é legítimo, só que quase sempre ele vem embrulhado numa confusão

Arquivo lido no contexto de uma requisição não é arquivo publicado

São duas coisas MUITO diferentes: uma é o agente precisar enxergar o código pra fazer o trabalho, a outra é seu código ficar disponível pra alguém de fora

E o que preocupa de verdade tem nome, lugar e prazo: um caminho no seu disco, um período de retenção, um comando que envia histórico

Bora separar isso direitinho? Neste post você vê o que sai da sua máquina, pra onde vai, quanto tempo fica guardado e o que dá pra desligar 🙂

O que sai da sua máquina quando você usa o Claude Code

Primeiro o mapa, porque sem ele a conversa vira achismo

São quatro destinos distintos, e cada um carrega uma coisa diferente

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Repara numa coisa: o destino que mais gera pânico (a API) é o que menos surpreende, porque é literalmente como o agente funciona

O <project> daquele caminho é o próprio diretório de trabalho, com os caracteres não alfanuméricos trocados por hífen

Dois casos que fogem do padrão e vale conhecer:

• No Claude Code na web, o repositório é clonado em uma VM isolada, e o código e os dados de sessão seguem as políticas de retenção e uso do tipo de conta
• Se você usa um provedor terceiro como Amazon Bedrock ou a Agent Platform do Google Cloud, ou está sem credenciais Anthropic configuradas, o /feedback grava o relatório num arquivo local em ~/.claude/feedback-bundles/ em vez de enviar pra Anthropic

Treino e retenção: quanto tempo seu código fica guardado

Aqui mora a pergunta que o pessoal realmente quer fazer: "tá, mas vão treinar modelo com o código do meu cliente?"

A resposta muda conforme o tipo de conta, então nada de generalizar

Aquelas exceções da API não são pegadinha, são casos nomeados: serviços de retenção mais longa sob controle do cliente, acordos específicos ou necessidade de aplicar a Política de Uso

E o ZDR existe pra alguns clientes da Claude Platform (API) e do Claude Code no Claude for Enterprise, sujeito à aprovação da Anthropic

Ou seja: dá pra ter, mas é caso a caso, não é o botão que você liga numa tarde

Onde fica o controle de treino:

Essa é a parte que gera confusão, então presta atenção

O controle fica nas Configurações de Privacidade da conta Claude, na opção Help Improve Claude (Ajude a melhorar o Claude), acessada pelo menu do nome > Settings > Privacy

Isso é configuração DE CONTA, no app Claude

Não é um comando que você roda dentro do Claude Code, e o efeito dela alcança as sessões feitas com aquela conta

O risco que quase ninguém checa: seu código em texto puro no próprio disco

Sintoma:

Você varre a máquina procurando onde código proprietário poderia estar fora do repositório

E acha: trechos de arquivo, saída de comando, coisa que você colou no chat pra pedir ajuda

Tudo isso num diretório que nunca entrou no seu .gitignore mental

Causa:

Tudo que passa por uma ferramenta cai na transcrição em disco: conteúdo de arquivo, saída de comando e texto colado

O Claude Code guarda essas transcrições localmente, em texto puro, em ~/.claude/projects/, por 30 dias por padrão, pra permitir retomar sessões

E aqui vem o detalhe que muita gente não sabe: transcrições e histórico não são criptografados em repouso

As permissões de arquivo do sistema operacional são a única proteção

Traduzindo: quem tem acesso ao seu usuário no sistema, tem acesso ao histórico

Solução e prevenção:

Três movimentos simples, na ordem:

• Ajuste o período de limpeza com cleanupPeriodDays, que é o parâmetro que controla os 30 dias padrão
• Trate ~/.claude como diretório sensível nas permissões do SO, do mesmo jeito que você trata uma pasta de chaves
• Pare de colar segredo no chat, porque texto colado também é gravado

Tome cuidado com o terceiro: colar um .env inteiro "só pra ele entender a config" derruba qualquer regra de deny que você configurou depois

Como limitar o que o Claude Code lê e envia: passo a passo

Agora a parte prática

Um aviso antes: config copiada de outro repo é a mesma fonte de dor que faz uma skill não rodar no seu projeto, então adapte cada passo ao seu caso em vez de colar cego

1. Escolha o diretório de trabalho com intenção. O Claude Code só escreve na pasta onde foi iniciado e nas subpastas dela, e não modifica arquivos em diretórios pai sem permissão explícita. O erro comum deste passo é abrir o agente na sua home: aí o "escopo" vira a máquina inteira e você jogou fora a proteção que vinha de graça

2. Negue os caminhos sensíveis no settings.json. Regra de deny de Read é o jeito de impedir que as ferramentas de arquivo leiam um caminho:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Duas coisas boas de saber aqui: nome de arquivo sem caminho segue a semântica do gitignore e casa em qualquer profundidade, então Read(.env) e Read(**/.env) são equivalentes

E uma regra de deny de Read também bloqueia as ferramentas Edit e Write no mesmo caminho, com o Claude Code fazendo esforço pra deixar caminhos negados fora dos resultados de Grep e Glob

O erro comum deste passo é achar que precisa repetir a regra pra cada ferramenta

3. Entenda o limite do deny. As regras de deny de Read e Edit valem pras ferramentas internas de arquivo e pros comandos de arquivo que o Claude Code reconhece no Bash, tipo cat, head, tail e sed

Elas NÃO valem pra subprocessos arbitrários que leem ou escrevem por conta própria, como um script Python ou Node

O erro comum deste passo é dormir tranquilo com o deny configurado achando que ninguém consegue mais tocar naquele arquivo

4. Ligue o sandbox se quiser bloqueio de verdade. Antes do JSON, confere o ambiente, porque mudar o arquivo de configuração sozinho não basta em todo sistema: o sandbox roda em macOS, Linux e WSL2, Windows nativo não é suportado, e no Linux e no WSL2 é preciso instalar bubblewrap e socat antes

Com o ambiente atendido, ele é ligado no arquivo de configuração:

{
  "sandbox": {
    "enabled": true
  }
}

O sandbox aceita um sub-objeto filesystem (com allowWrite e denyRead) e um sub-objeto network (com allowedDomains e deniedDomains)

A diferença que importa: ele aplica as listas de filesystem na fronteira do sistema operacional, valendo pra todo subprocesso iniciado por um comando no sandbox, não só pras ferramentas de arquivo do Claude

É exatamente o buraco do passo 3, tampado

O erro comum deste passo é justamente pular a checagem de ambiente e achar que o JSON resolve em qualquer máquina, inclusive no Windows nativo

5. Use permissions.additionalDirectories com consciência. Diretórios listados ali concedem apenas acesso a arquivos e não carregam nenhuma configuração daquele diretório

Esses arquivos seguem as mesmas regras de permissão do diretório de trabalho original

O erro comum deste passo é adicionar o monorepo do lado esperando que o settings.json de lá venha junto: não vem

6. Conte com o .gitignore, mas só até onde ele alcança. As buscas de conteúdo respeitam o .gitignore por padrão, então caminhos já listados lá, tipo node_modules/, dist/ e build/, ficam fora dos resultados

Porém a ferramenta Glob não respeita o .gitignore por padrão, e esse comportamento pode ser ajustado com CLAUDE_CODE_GLOB_NO_IGNORE=false

O erro comum deste passo é tratar .gitignore como fronteira de segurança, quando ele é fronteira de RUÍDO

7. Desligue o tráfego não essencial. Uma variável resolve o pacote todo:

export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

Ela equivale a DISABLE_TELEMETRY=1, DISABLE_ERROR_REPORTING=1, DISABLE_FEEDBACK_COMMAND=1 e CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 juntos

O erro comum geral, que vale pros sete passos: manter segredo em arquivo dentro do projeto em vez de variável de ambiente, e imaginar que negar leitura resolve exfiltração por script

Que nível de blindagem cada cenário pede

Nem todo mundo precisa da mesma armadura, e configurar demais só cansa você

Projeto pessoal ou open source: conta de consumo resolve. A única coisa que merece um olhar é a opção de melhoria de modelo e a retenção que vem junto dela: ligada são 5 anos, desligada são 30 dias

Freelancer com código de cliente e NDA: aqui aperta. Deny nos caminhos de segredo, segredo em variável de ambiente (nunca em arquivo versionado), cleanupPeriodDays curto e disciplina com /feedback, /bug e /share, porque eles enviam o histórico da conversa incluindo código e a transcrição compartilhada fica retida por 5 anos

Time em conta comercial: Team, Enterprise e API já vêm sem treino por padrão e com retenção padrão de 30 dias, então o esforço vai pro sandbox, que é o que contém subprocesso rebelde (lembrando do requisito de ambiente: macOS, Linux ou WSL2)

Empresa com exigência contratual forte: aí a conversa é ZDR, aprovado caso a caso na Claude Platform (API) e no Claude Code no Claude for Enterprise. Config no editor não substitui contrato, beleza?

Duas defesas que valem pra todo mundo e vêm de fábrica:

A primeira execução em um codebase novo e a adição de novos servidores MCP exigem verificação de confiança na pasta

É o mesmo cuidado de conferir o que um plugin instala antes de sair adicionando coisa no seu ambiente

E contra prompt injection, o web fetch usa uma janela de contexto separada, com os resultados de busca sendo resumidos em vez de entrarem crus no contexto

Veredito: vazamento, exposição e o que realmente muda o risco

Tem três coisas que viram uma só na cabeça das pessoas, e é aí que a discussão azeda

Um: enviar código pra API como parte do funcionamento do agente. Isso não é vazamento, é o produto operando, e rodando com credenciais Anthropic a comunicação é direta do terminal pra API da Anthropic, sem intermediários (num provedor terceiro, o tráfego passa pela infra dele)

Dois: esse código ser usado pra treino. Depende do tipo de conta e da configuração escolhida, e em conta comercial não acontece por padrão

Três: publicar código. Não é nada do que está descrito acima

Agora os pontos que de fato aumentam exposição, e olha que interessante, quase todos estão sob seu controle:

• A transcrição local em texto puro, sem criptografia em repouso, protegida apenas pelas permissões do SO
• /feedback, /bug e /share, que mandam o histórico com código e ficam guardados por 5 anos
• Diretório de trabalho largo demais, tipo abrir na home
• Subprocessos, que passam por fora das regras de deny

Pra projeto pessoal e a maioria dos times em conta comercial, o padrão mais um deny bem feito já dá conta

Pra quem lida com código de cliente sob contrato, sandbox deixa de ser luxo

E pra quem tem cláusula contratual pesada, nenhuma variável de ambiente substitui um acordo formal

Conclusão

O controle aqui existe em camadas, e cada camada resolve um risco diferente: a conta define treino e retenção, a configuração define o que a ferramenta lê, o sandbox define o que o sistema operacional deixa acontecer, e o disco local guarda o histórico que ninguém lembra que existe

Misturar as camadas é o que produz aquela sensação vaga de "será que vaza?"

Separando, a coisa fica administrável 😀

Próximo passo, pequeno e concreto, antes de apontar o agente pro próximo repositório de cliente:

Abra as Configurações de Privacidade da conta Claude e confira a opção Help Improve Claude

Abra o settings.json e adicione o deny dos caminhos sensíveis

E dá uma olhada no que já está gravado em ~/.claude/projects/

São cinco minutos que valem mais que qualquer discussão de fórum sobre o assunto

até o próximo post!