Os agentes de código guardam suas chaves de API nas transcrições?

Sim, podem. Claude Code, Codex CLI, Cursor e OpenCode mantêm um registro das suas conversas, e uma chave que passa por uma chamada de ferramenta, como a leitura de um arquivo ou um comando que imprime o ambiente, pode acabar nesse registro. A documentação do Claude Code diz isso claramente: os arquivos dele são texto simples, e tudo o que passa por uma ferramenta é gravado em uma transcrição no disco.

Este guia mostra onde cada um dos quatro agentes armazena o histórico, o que cada fabricante documenta sobre retenção e envio, o que o zn-gate faz a respeito e o que não faz, e uma lista para limpar. Cada afirmação sobre um fabricante tem link para a página dele. Onde não encontramos nada na documentação, dizemos isso em vez de supor.

Por que uma chave acabaria em uma transcrição?

Um agente trabalha chamando ferramentas: ler um arquivo, executar um comando, buscar em uma pasta, chamar um servidor MCP. O resultado de cada chamada volta ao modelo, e o agente mantém um registro da conversa para que você possa retomá-la depois. Se o resultado contém AWS_ACCESS_KEY_ID=... porque o agente leu um .env ou executou env, a chave está no contexto do modelo e no registro.

Há, portanto, duas cópias a considerar. Uma está no seu disco, na pasta de histórico do agente. A outra está onde o provedor do modelo processa e pode reter suas requisições. Limpar a primeira não afeta a segunda.

Onde cada agente armazena o histórico?

Claude Code

A documentação de dados da aplicação do Claude Code diz que os arquivos em ~/.claude são texto simples e que tudo o que passa por uma ferramenta é gravado em uma transcrição no disco: conteúdo de arquivos, saída de comandos e texto colado. A conversa completa fica em projects/<project>/<session>.jsonl, com cada mensagem, chamada de ferramenta e resultado. As transcrições de subagentes têm a própria pasta, e saídas grandes de ferramentas são despejadas em uma pasta tool-results/ ao lado da sessão.

O Claude Code apaga esses arquivos quando passam de cleanupPeriodDays. O padrão é 30 dias e o mínimo é 1; a documentação diz que definir 0 gera um erro de validação. A página de uso de dados repete os 30 dias padrão para o cache local e remete à mesma página para saber como limpá-lo. Ela também observa que as transcrições de sessões iniciadas ou continuadas por último no Claude Desktop ou no Cowork ficam isentas desse limite por padrão.

Para encurtar o prazo, defina um valor menor em ~/.claude/settings.json:

{
  "cleanupPeriodDays": 1
}

A mesma página (armazenamento em texto simples) lista formas de guardar menos. Definir a variável de ambiente CLAUDE_CODE_SKIP_PROMPT_HISTORY evita gravar transcrições e o histórico de prompts em qualquer modo. No modo não interativo, você pode passar --no-session-persistence junto com -p. O claude purge apaga as transcrições, a memória e o histórico de prompts que o Claude Code guarda de um projeto, depois de mostrar o plano e pedir confirmação. Os arquivos também são arquivos comuns, então você pode apagá-los por conta própria.

O histórico de prompts é um arquivo separado. O ~/.claude/history.jsonl guarda cada prompt que você digitou, e a documentação diz que a limpeza por idade não remove essas entradas, a menos que a configuração HIPAA se aplique. Uma chave colada em um prompt pode continuar ali depois que as transcrições sumirem.

Codex CLI

A página de variáveis de ambiente da OpenAI diz que CODEX_HOME define a raiz do estado do Codex, que inclui configuração, autenticação, logs, sessões, skills e metadados do pacote, e que o padrão é ~/.codex. A referência de configuração tem duas opções de histórico: history.persistence ("Control whether Codex saves session transcripts to history.jsonl", com os valores save-all ou none) e history.max_bytes, que limita o tamanho do arquivo de histórico descartando as entradas mais antigas.

# ~/.codex/config.toml
[history]
persistence = "none"

Para automação, a referência de comandos lista codex exec --ephemeral: "Run without persisting session rollout files to disk".

O que não encontramos nas páginas lidas: um período de retenção para os arquivos de sessão, nem a estrutura exata de subpastas em sessions. Se precisar desse detalhe, olhe a sua própria pasta ~/.codex.

Cursor

A página de ajuda sobre privacidade do Cursor e a visão geral de uso de dados descrevem o que acontece no servidor, e nenhuma diz onde o histórico de chat fica armazenado no seu computador nem como apagá-lo. É uma lacuna no que conseguimos verificar, não uma afirmação de que nada é armazenado. Veja as configurações do próprio aplicativo para controles de histórico.

O lado do servidor está documentado. Com o Privacy Mode ativado, o Cursor diz que seus dados não são usados para treinamento e que tem acordos de retenção zero com seus provedores de modelos, com uma exceção: se seus prompts ou conversas acionam detectores de abuso, os dados podem ser armazenados para investigação. Com o Privacy Mode desativado, a visão geral diz que o Cursor pode manter e usar dados da base de código, prompts, ações do editor e trechos de código para melhorar seus recursos de IA. As requisições passam pelo backend do Cursor mesmo quando você usa sua própria chave de API, e a página de ajuda diz que a retenção zero não se aplica nesse caso: seus dados seguem a política de privacidade do seu provedor, e o Cursor guarda temporariamente em cache o conteúdo de arquivos nos servidores dele para reduzir a latência. A visão geral não informa períodos de retenção para o armazenamento do próprio Cursor.

OpenCode

A página de solução de problemas do OpenCode lista os locais. Os logs ficam em ~/.local/share/opencode/log/. Os dados de sessão ficam na pasta project/ dentro de ~/.local/share/opencode/: em <project-slug>/storage/ quando o projeto está em um repositório Git, e em global/storage/ caso contrário. No Windows, a pasta base é %USERPROFILE%\.local\share\opencode.

A documentação atual do OpenCode que conseguimos abrir não descreve o compartilhamento de sessões nem uma configuração para isso. Se você compartilhou uma sessão, consulte a ajuda da sua versão para saber como remover o link.

Não encontramos um período de retenção documentado para os dados locais de sessão.

Os agentes enviam a transcrição?

Para a chamada ao modelo, sim, por construção: o agente envia seus prompts e os resultados das ferramentas ao provedor do modelo, e é assim que o modelo chega a ver uma chave. O que o fabricante guarda depois depende do produto e do plano.

No Claude Code, a página de uso de dados diz que os dados enviados incluem todos os prompts do usuário e as saídas do modelo, criptografados em trânsito. A retenção da Anthropic depende da conta: em Free, Pro e Max, 5 anos se você permitir o uso dos dados para melhorar o modelo e 30 dias se não permitir; em Team, Enterprise e API, 30 dias por padrão. A retenção zero está disponível para o Claude Code no Claude for Enterprise, ativada por organização para contas qualificadas.

A mesma página lista os casos em que uma transcrição é enviada de propósito. Executar /feedback (e /bug ou /share) envia uma cópia do seu histórico de conversa, e esses relatórios ficam retidos por 5 anos. Se você responder Sim à pergunta opcional "Can Anthropic look at your session transcript" que vem depois de uma pesquisa de sessão, a transcrição é enviada; padrões conhecidos de chaves e tokens são ocultados antes do envio, o restante do conteúdo não. Você pode desativar o comando de feedback com DISABLE_FEEDBACK_COMMAND=1 e a pesquisa com CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1.

No Codex CLI, as páginas de documentação que lemos não descrevem envio dos arquivos de sessão locais, e não afirmamos o que a OpenAI retém nos servidores dela. Isso depende de como você faz login e do seu plano, então consulte os termos da OpenAI para a sua conta. Para Cursor e OpenCode, veja as seções acima.

O que o zn-gate muda e o que não muda?

O zn-gate é uma camada local entre o seu agente e as ferramentas que ele usa. Quando uma ferramenta devolve saída, o zn-gate substitui nela os segredos, como chaves da AWS, tokens do GitHub, JWTs, chaves privadas e senhas em URLs de bancos de dados, por marcadores como __ZN_AWS_KEY_1__ antes que o modelo veja o resultado. Como a transcrição registra o que foi mostrado ao modelo, uma transcrição nova contém o marcador em vez do valor. Um segredo colado em um prompt é bloqueado em vez de enviado.

No Claude Code, no Codex CLI e no OpenCode, o zn-gate limpa a saída das ferramentas do próprio agente. No Cursor, só a saída das ferramentas MCP é limpa. A saída do shell e o conteúdo dos arquivos não podem ser reescritos ali, então valores em arquivos que o agente lê, ou que comandos imprimem, podem chegar ao modelo.

Limites a ter em mente, conforme o modelo de ameaças do zn-gate:

• Ele não limpa transcrições gravadas antes da instalação. Esses arquivos continuam com o que tinham.
• Ele não controla o que um fabricante de agente armazena nos servidores dele. Reduz o que é enviado e não consegue recolher o que foi enviado antes.
• O Codex não consegue reescrever a saída das ferramentas, então o zn-gate substitui o resultado que o modelo vê. O log de sessão do próprio Codex em ~/.codex/sessions mantém a saída original.
• No Claude Code, a transcrição contém a saída limpa das ferramentas, mas um prompt que o zn-gate bloqueou fica nela em texto claro, como diz a própria documentação do Claude Code. O comando mostrado em uma caixa de confirmação quando o zn-gate restaura um valor para um comando local também é registrado ali.
• O OpenCode grava a saída ao vivo de um comando em execução antes que o zn-gate possa vê-la, então essa parte fica no banco de dados local do OpenCode.

O que fazer se uma chave pode já estar em uma transcrição?

1. Rotacione a chave. Crie uma nova no provedor e revogue a antiga. Apagar um arquivo não desfaz uma cópia enviada a um modelo ou incluída em um backup, por isso este passo vem primeiro.

2. Encontre as transcrições que a contêm. Busque o prefixo da chave nas pastas de histórico. Por exemplo, no macOS ou no Linux:

   grep -rl "AKIA" ~/.claude ~/.codex ~/.local/share/opencode 2>/dev/null

   Troque AKIA pelo prefixo da chave que você procura. Use um prefixo, não a chave inteira, para que a chave não fique no histórico do seu shell.

3. Apague o que não precisa. Remova os arquivos de sessão correspondentes das pastas acima, ou defina cleanupPeriodDays com um valor baixo no Claude Code e persistence = "none" no Codex. No Cursor, use os controles de histórico do próprio aplicativo, já que não encontramos um caminho documentado. No Claude Code, claude purge também remove as linhas do projeto em history.jsonl.

4. Confira as outras cópias. Backups, sincronização em nuvem da sua pasta pessoal e qualquer sessão que você tenha compartilhado. Se você compartilhou uma sessão do OpenCode, remova o link como a ajuda da sua versão descreve. No Claude Code, a Anthropic mantém os relatórios de /feedback como descrito acima.

5. Evite novas cópias. Tire os valores dos lugares que o agente lê e coloque um filtro de segredos no caminho.

Como evito que novas chaves cheguem às transcrições?

Instale o zn-gate e mova os valores do seu .env para o cofre local dele. O arquivo mantém marcadores, então lê-lo não mostra valor nenhum:

npx -y zn-gate init
npx -y zn-gate unlock
npx -y zn-gate env shadow .env
npx -y zn-gate check

O init pergunta antes de cada mudança e configura Claude Code, Codex CLI, Cursor e OpenCode onde os encontrar. O unlock cria o cofre na primeira vez. O env shadow troca os valores reais do .env por marcadores como __ZN_STRIPE_KEY__ e guarda uma cópia criptografada que o zn env unshadow pode restaurar. O check testa a proteção com um segredo falso em uma pasta temporária e diz qual agente não está protegido. Para os detalhes da configuração, veja como impedir que Claude Code, Codex CLI, Cursor e OpenCode leiam seu .env com um comando.

O que este guia não cobre?

• Caminhos e configurações mudam entre versões de cada agente. O que está acima vem da documentação dos fabricantes na data da redação, e a estrutura de arquivos dentro de cada pasta pode ser diferente na sua versão.
• Não testamos a exclusão em cada plataforma, e não verificamos o que os fabricantes fazem com os dados apagados nos servidores deles.
• Sessões na nuvem, produtos de chat e outros editores ficam de fora. O zn-gate não cobre sessões do Claude Code na nuvem, o Cowork nem o chat.
• Um filtro de segredos trabalha com os formatos que reconhece. Um segredo em um formato desconhecido pode passar, e por isso rotacionar a chave é o primeiro passo depois de um vazamento.

Perguntas frequentes

Os agentes de código salvam minhas chaves de API no histórico de conversas?

Podem salvar. A documentação do Claude Code diz que tudo o que passa por uma ferramenta é gravado em uma transcrição em texto simples no disco, incluindo o conteúdo de arquivos e a saída de comandos. O Codex CLI documenta que mantém os arquivos de sessão em CODEX_HOME, e o OpenCode documenta uma pasta local de sessões. As páginas do Cursor que lemos não dizem onde o histórico de chat fica armazenado localmente.

Onde o Claude Code guarda as transcrições e por quanto tempo?

Em ~/.claude/projects/, com um arquivo .jsonl por sessão. O Claude Code as apaga depois de cleanupPeriodDays dias: 30 por padrão, com mínimo de 1.

Como impeço o Codex CLI de salvar o histórico?

Defina persistence como none na tabela [history] do config.toml para parar de gravar o history.jsonl, e execute codex exec com --ephemeral para que uma execução não interativa não grave arquivos de sessão. A documentação não informa um período de retenção para os arquivos de sessão interativos.

O zn-gate limpa as transcrições que já existem?

Não. O zn-gate substitui os segredos na saída das ferramentas por marcadores antes que o modelo os veja, então as novas transcrições contêm marcadores em vez de valores. Ele não reescreve arquivos gravados antes da instalação e não controla o que o fabricante do agente armazena nos servidores dele.

O que fazer se uma chave chegou a uma transcrição?

Rotacione a chave primeiro no provedor, porque apagar um arquivo não desfaz uma cópia enviada a um modelo ou incluída em um backup. Depois apague as transcrições que a contêm e mova os valores do seu .env para o cofre com npx -y zn-gate env shadow .env.

O zn-gate protege o Cursor da mesma forma que os outros agentes?

Não totalmente. No Cursor, o zn-gate limpa apenas a saída das ferramentas MCP. A saída do shell e o conteúdo dos arquivos não podem ser reescritos ali, então tire os valores dos arquivos com npx -y zn-gate env shadow .env. Um segredo colado em um prompt é bloqueado nos quatro agentes.

---

Para testar nos seus próprios agentes, execute npx -y zn-gate init (MIT, local, sem conta) e depois npx -y zn-gate check. O código está no GitHub e os guias de cada agente começam em Instalação. Os caminhos que um comando de shell pode usar para chegar a um arquivo protegido estão em como um agente de código poderia ler seu .env de forma indireta.