Les agents de code gardent-ils vos clés d'API dans leurs transcriptions ?

Q: Où Claude Code garde-t-il ses transcriptions et pendant combien de temps ?

Dans ~/.claude/projects/, avec un fichier .jsonl par session. Claude Code les supprime après cleanupPeriodDays jours : 30 par défaut, avec un minimum de 1.

Q: Comment empêcher Codex CLI d'enregistrer l'historique ?

Mettez persistence à none dans la table [history] de config.toml pour arrêter l'écriture de history.jsonl, et lancez codex exec avec --ephemeral pour qu'une exécution non interactive n'écrive pas de fichiers de session. La documentation n'indique pas de durée de conservation pour les fichiers de session interactifs.

Oui, c'est possible. Claude Code, Codex CLI, Cursor et OpenCode conservent une trace de vos conversations, et une clé qui passe par un appel d'outil, comme la lecture d'un fichier ou une commande qui affiche l'environnement, peut se retrouver dans cette trace. La documentation de Claude Code le dit clairement : ses fichiers sont en texte brut, et tout ce qui passe par un outil est écrit dans une transcription sur le disque.

Ce guide indique où chacun des quatre agents stocke son historique, ce que chaque éditeur documente sur la conservation et les envois, ce que zn-gate fait à ce sujet et ce qu'il ne fait pas, puis une liste pour nettoyer. Chaque affirmation sur un éditeur renvoie vers sa propre page. Quand nous n'avons rien trouvé dans la documentation, nous le disons au lieu de deviner.

Pourquoi une clé finirait-elle dans une transcription ?

Un agent travaille en appelant des outils : lire un fichier, exécuter une commande, chercher dans un dossier, appeler un serveur MCP. Le résultat de chaque appel retourne au modèle, et l'agent garde un journal de la conversation pour que vous puissiez la reprendre. Si le résultat contient AWS_ACCESS_KEY_ID=... parce que l'agent a lu un fichier .env ou lancé env, la clé est dans le contexte du modèle et dans le journal.

Il y a donc deux copies à considérer. L'une est sur votre disque, dans le dossier d'historique de l'agent. L'autre est là où le fournisseur du modèle traite et peut conserver vos requêtes. Nettoyer la première ne touche pas la seconde.

Où chaque agent stocke-t-il son historique ?

Agent	Stockage local, selon la documentation	Contrôle documenté
Claude Code	`~/.claude/projects/<project>/<session>.jsonl`, texte brut, avec les grosses sorties d'outils dans un dossier `tool-results/`	`cleanupPeriodDays`, 30 jours par défaut, minimum 1, `CLAUDE_CODE_SKIP_PROMPT_HISTORY`, `claude purge`
Codex CLI	Sous `CODEX_HOME` (par défaut `~/.codex`) : configuration, authentification, journaux et sessions	`history.persistence`, `history.max_bytes`, `codex exec --ephemeral`
Cursor	Non indiqué dans les pages que nous avons lues	Privacy Mode (côté serveur)
OpenCode	`~/.local/share/opencode/`, données de session dans `project/<project-slug>/storage/`	Non indiqué dans les pages que nous avons lues

Claude Code

La documentation sur les données d'application de Claude Code indique que les fichiers de ~/.claude sont en texte brut et que tout ce qui passe par un outil est écrit dans une transcription sur le disque : contenu des fichiers, sortie des commandes et texte collé. La conversation complète se trouve dans projects/<project>/<session>.jsonl, avec chaque message, appel d'outil et résultat. Les transcriptions des sous-agents ont leur propre dossier, et les grosses sorties d'outils sont déversées dans un dossier tool-results/ à côté de la session.

Claude Code supprime ces fichiers lorsqu'ils dépassent cleanupPeriodDays. La valeur par défaut est de 30 jours et le minimum est de 1 ; la documentation précise que 0 provoque une erreur de validation. La page sur l'utilisation des données reprend les 30 jours par défaut pour le cache local et renvoie à la même page pour savoir comment l'effacer. Elle note aussi que les transcriptions des sessions démarrées ou reprises en dernier dans Claude Desktop ou Cowork sont exemptées de cette limite par défaut.

Pour raccourcir le délai, indiquez une valeur plus basse dans ~/.claude/settings.json :

{
  "cleanupPeriodDays": 1
}

La même page (stockage en texte brut) liste des moyens d'en conserver moins. Définir la variable d'environnement CLAUDE_CODE_SKIP_PROMPT_HISTORY évite d'écrire les transcriptions et l'historique des prompts, quel que soit le mode. En mode non interactif, vous pouvez passer --no-session-persistence avec -p. claude purge supprime les transcriptions, la mémoire et l'historique des prompts que Claude Code conserve pour un projet, après avoir affiché le plan et demandé confirmation. Ce sont aussi des fichiers ordinaires, vous pouvez donc les supprimer vous-même.

L'historique des prompts est un fichier à part. ~/.claude/history.jsonl garde chaque prompt que vous avez saisi, et la documentation indique que le nettoyage par ancienneté ne supprime pas ces entrées, sauf si la configuration HIPAA s'applique. Une clé collée dans un prompt peut donc y rester après la disparition des transcriptions.

Codex CLI

La page des variables d'environnement d'OpenAI indique que CODEX_HOME définit la racine de l'état de Codex, qui comprend la configuration, l'authentification, les journaux, les sessions, les skills et les métadonnées du paquet, et que la valeur par défaut est ~/.codex. La référence de configuration contient deux paramètres d'historique : history.persistence (« Control whether Codex saves session transcripts to history.jsonl », avec les valeurs save-all ou none) et history.max_bytes, qui plafonne la taille du fichier d'historique en supprimant les entrées les plus anciennes.

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

Pour l'automatisation, la référence des commandes indique codex exec --ephemeral : « Run without persisting session rollout files to disk ».

Ce que nous n'avons pas trouvé dans les pages lues : une durée de conservation pour les fichiers de session, ni l'organisation exacte des sous-dossiers sous sessions. Si vous avez besoin de ce détail, regardez votre propre dossier ~/.codex.

Cursor

La page d'aide sur la confidentialité de Cursor et son aperçu de l'utilisation des données décrivent ce qui se passe côté serveur, et aucune n'indique où l'historique des conversations est stocké sur votre ordinateur ni comment le supprimer. C'est une lacune dans ce que nous avons pu vérifier, pas une affirmation que rien n'est stocké. Consultez les réglages de l'application pour d'éventuels contrôles d'historique.

Le côté serveur est documenté. Avec Privacy Mode activé, Cursor indique que vos données ne servent pas à l'entraînement et qu'il a des accords de rétention zéro avec ses fournisseurs de modèles, avec une exception : si vos prompts ou conversations déclenchent des détecteurs d'abus, les données peuvent être stockées pour enquête. Avec Privacy Mode désactivé, l'aperçu indique que Cursor peut conserver et utiliser les données du code, les prompts, les actions de l'éditeur et des extraits de code pour améliorer ses fonctions d'IA. Les requêtes passent par le backend de Cursor même si vous utilisez votre propre clé d'API, et la page d'aide indique que la rétention zéro ne s'applique pas dans ce cas : vos données suivent la politique de confidentialité de votre fournisseur, et Cursor met temporairement en cache le contenu des fichiers sur ses serveurs pour réduire la latence. L'aperçu ne donne pas de durées de conservation pour le stockage propre de Cursor.

OpenCode

La page de dépannage d'OpenCode indique les emplacements. Les journaux sont dans ~/.local/share/opencode/log/. Les données de session sont dans le dossier project/ sous ~/.local/share/opencode/ : dans <project-slug>/storage/ quand le projet est dans un dépôt Git, et dans global/storage/ sinon. Sous Windows, le dossier de base est %USERPROFILE%\.local\share\opencode.

La documentation actuelle d'OpenCode que nous avons pu ouvrir ne décrit ni le partage de sessions ni de paramètre pour cela. Si vous avez partagé une session, consultez l'aide de votre version pour savoir comment supprimer le lien.

Nous n'avons pas trouvé de durée de conservation documentée pour les données locales de session.

Les agents envoient-ils la transcription ?

Pour l'appel au modèle, oui, par conception : l'agent envoie vos prompts et les résultats des outils au fournisseur du modèle, et c'est ainsi que le modèle voit une clé en premier lieu. Ce que l'éditeur conserve ensuite dépend du produit et de l'offre.

Pour Claude Code, la page sur l'utilisation des données indique que les données envoyées comprennent tous les prompts de l'utilisateur et les sorties du modèle, chiffrés en transit. La conservation chez Anthropic dépend du compte : pour Free, Pro et Max, 5 ans si vous autorisez l'utilisation des données pour améliorer le modèle et 30 jours sinon ; pour Team, Enterprise et API, 30 jours par défaut. La rétention zéro est disponible pour Claude Code avec Claude for Enterprise, activée par organisation pour les comptes éligibles.

La même page énumère les cas où une transcription est envoyée volontairement. Lancer /feedback (ainsi que /bug ou /share) envoie une copie de votre historique de conversation, et ces rapports sont conservés 5 ans. Si vous répondez Oui à la question facultative « Can Anthropic look at your session transcript » qui suit un sondage de session, la transcription est envoyée ; les formats connus de clés et de jetons sont masqués avant l'envoi, pas le reste du contenu. Vous pouvez désactiver la commande de retour avec DISABLE_FEEDBACK_COMMAND=1 et le sondage avec CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1.

Pour Codex CLI, les pages de documentation que nous avons lues ne décrivent pas d'envoi des fichiers de session locaux, et nous n'affirmons pas ce qu'OpenAI conserve sur ses serveurs. Cela dépend de votre mode de connexion et de votre offre : consultez les conditions d'OpenAI pour votre compte. Pour Cursor et OpenCode, voir les sections ci-dessus.

Que change zn-gate, et que ne change-t-il pas ?

zn-gate est une couche locale placée entre votre agent et les outils qu'il utilise. Quand un outil renvoie une sortie, zn-gate y remplace les secrets, comme les clés AWS, les jetons GitHub, les JWT, les clés privées et les mots de passe dans les URL de bases de données, par des marqueurs tels que __ZN_AWS_KEY_1__ avant que le modèle ne voie le résultat. Comme la transcription enregistre ce qui a été montré au modèle, une nouvelle transcription contient le marqueur au lieu de la valeur. Un secret collé dans un prompt est bloqué au lieu d'être envoyé.

Dans Claude Code, Codex CLI et OpenCode, zn-gate nettoie la sortie des outils propres à l'agent. Dans Cursor, seule la sortie des outils MCP est nettoyée. La sortie du shell et le contenu des fichiers ne peuvent pas y être réécrits : les valeurs présentes dans les fichiers que l'agent lit, ou affichées par les commandes, peuvent donc atteindre le modèle.

Limites à garder en tête, d'après le modèle de menaces de zn-gate :

Il ne nettoie pas les transcriptions écrites avant son installation. Ces fichiers contiennent toujours ce qu'ils contenaient.
Il ne contrôle pas ce qu'un éditeur d'agent stocke sur ses serveurs. Il réduit ce qui est envoyé et ne peut pas rappeler ce qui l'a été avant.
Codex ne peut pas réécrire la sortie des outils, donc zn-gate remplace le résultat que voit le modèle. Le journal de session propre à Codex dans ~/.codex/sessions conserve la sortie d'origine.
Dans Claude Code, la transcription contient la sortie nettoyée des outils, mais un prompt que zn-gate a bloqué y reste en clair, comme l'indique la documentation de Claude Code elle-même. La commande affichée dans une boîte de confirmation quand zn-gate restaure une valeur pour une commande locale y est aussi enregistrée.
OpenCode écrit la sortie en direct d'une commande en cours avant que zn-gate puisse la voir, cette partie reste donc dans la base locale d'OpenCode.

Que faire si une clé est peut-être déjà dans une transcription ?

Renouvelez la clé. Créez-en une nouvelle chez le fournisseur et révoquez l'ancienne. Supprimer un fichier n'annule pas une copie envoyée à un modèle ou incluse dans une sauvegarde : cette étape passe donc en premier.
Trouvez les transcriptions qui la contiennent. Cherchez le préfixe de la clé dans les dossiers d'historique. Par exemple, sous macOS ou Linux :
```
grep -rl "AKIA" ~/.claude ~/.codex ~/.local/share/opencode 2>/dev/null
```
Remplacez AKIA par le préfixe de la clé recherchée. Utilisez un préfixe, pas la clé entière, pour que la clé ne se retrouve pas dans l'historique de votre shell.
Supprimez ce dont vous n'avez pas besoin. Retirez les fichiers de session correspondants des dossiers ci-dessus, ou mettez cleanupPeriodDays à une valeur basse pour Claude Code et persistence = "none" pour Codex. Pour Cursor, utilisez les contrôles d'historique de l'application, faute de chemin documenté. Pour Claude Code, claude purge supprime aussi les lignes du projet dans history.jsonl.
Vérifiez les autres copies. Sauvegardes, synchronisation cloud de votre dossier personnel et sessions que vous avez partagées. Si vous avez partagé une session OpenCode, supprimez le lien comme le décrit l'aide de votre version. Dans Claude Code, les rapports /feedback sont conservés par Anthropic comme décrit plus haut.
Évitez de nouvelles copies. Sortez les valeurs des endroits que lit l'agent et placez un filtre de secrets sur le chemin.

Comment éviter que de nouvelles clés n'atteignent les transcriptions ?

Installez zn-gate et déplacez les valeurs de votre .env dans son coffre local. Le fichier garde des marqueurs, donc sa lecture ne montre aucune valeur :

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

init demande confirmation avant chaque changement et configure Claude Code, Codex CLI, Cursor et OpenCode là où il les trouve. unlock crée le coffre la première fois. env shadow remplace les valeurs réelles de .env par des marqueurs comme __ZN_STRIPE_KEY__ et garde une copie chiffrée que zn env unshadow peut restaurer. check teste la protection avec un faux secret dans un dossier temporaire et indique quel agent n'est pas protégé. Pour le détail de la configuration, voir comment empêcher Claude Code, Codex CLI, Cursor et OpenCode de lire votre .env avec une seule commande.

Que ne couvre pas ce guide ?

Les chemins et les paramètres changent d'une version à l'autre de chaque agent. Ce qui précède provient de la documentation des éditeurs au moment de la rédaction, et l'organisation des fichiers dans chaque dossier peut différer dans votre version.
Nous n'avons pas testé la suppression sur chaque plateforme, et nous n'avons pas vérifié ce que les éditeurs font des données supprimées sur leurs serveurs.
Les sessions cloud, les produits de chat et les autres éditeurs sont hors périmètre. zn-gate ne couvre pas les sessions Claude Code dans le cloud, Cowork ni le chat.
Un filtre de secrets travaille sur les formats qu'il reconnaît. Un secret dans un format inconnu peut passer, c'est pourquoi le renouvellement est la première étape après une fuite.

Questions fréquentes

Les agents de code enregistrent-ils mes clés d'API dans leur historique de conversation ?

Ils peuvent le faire. La documentation de Claude Code indique que tout ce qui passe par un outil est écrit dans une transcription en texte brut sur le disque, y compris le contenu des fichiers et la sortie des commandes. Codex CLI documente qu'il conserve ses fichiers de session sous CODEX_HOME, et OpenCode documente un dossier local de sessions. Les pages de Cursor que nous avons lues n'indiquent pas où l'historique des conversations est stocké en local.

Où Claude Code garde-t-il ses transcriptions et pendant combien de temps ?

Dans ~/.claude/projects/, avec un fichier .jsonl par session. Claude Code les supprime après cleanupPeriodDays jours : 30 par défaut, avec un minimum de 1.

Comment empêcher Codex CLI d'enregistrer l'historique ?

Mettez persistence à none dans la table [history] de config.toml pour arrêter l'écriture de history.jsonl, et lancez codex exec avec --ephemeral pour qu'une exécution non interactive n'écrive pas de fichiers de session. La documentation n'indique pas de durée de conservation pour les fichiers de session interactifs.

zn-gate nettoie-t-il les transcriptions qui existent déjà ?

Non. zn-gate remplace les secrets de la sortie des outils par des marqueurs avant que le modèle ne les voie, donc les nouvelles transcriptions contiennent des marqueurs au lieu des valeurs. Il ne réécrit pas les fichiers écrits avant son installation et ne contrôle pas ce que l'éditeur de l'agent stocke sur ses serveurs.

Que faire si une clé s'est retrouvée dans une transcription ?

Renouvelez-la d'abord chez le fournisseur, car supprimer un fichier n'annule pas une copie envoyée à un modèle ou incluse dans une sauvegarde. Supprimez ensuite les transcriptions qui la contiennent et déplacez les valeurs de votre .env dans le coffre avec npx -y zn-gate env shadow .env.

zn-gate protège-t-il Cursor comme les autres agents ?

Pas entièrement. Dans Cursor, zn-gate ne nettoie que la sortie des outils MCP. La sortie du shell et le contenu des fichiers ne peuvent pas y être réécrits : sortez donc les valeurs des fichiers avec npx -y zn-gate env shadow .env. Un secret collé dans un prompt est bloqué dans les quatre agents.

Pour l'essayer sur vos propres agents, lancez npx -y zn-gate init (MIT, local, sans compte), puis npx -y zn-gate check. Le code est sur GitHub et les guides pour chaque agent commencent à Installation. Les chemins qu'une commande shell peut emprunter pour atteindre un fichier protégé sont décrits dans comment un agent de code pourrait lire votre .env de façon indirecte.