¿Guardan los agentes de código tus claves de API en sus transcripciones?

Sí, pueden. Claude Code, Codex CLI, Cursor y OpenCode guardan un registro de tus conversaciones, y una clave que pasa por una llamada a una herramienta, como la lectura de un fichero o un comando que imprime el entorno, puede acabar en ese registro. La documentación de Claude Code lo dice sin rodeos: sus ficheros están en texto plano y todo lo que pasa por una herramienta se escribe en una transcripción en el disco.

Esta guía explica dónde guarda su historial cada uno de los cuatro agentes, qué documenta cada fabricante sobre retención y subidas, qué hace zn-gate al respecto y qué no hace, y una lista para limpiar. Cada afirmación sobre un fabricante enlaza a su propia página. Donde no encontramos nada en la documentación, lo decimos en lugar de suponer.

¿Por qué acabaría una clave en una transcripción?

Un agente trabaja llamando a herramientas: leer un fichero, ejecutar un comando, buscar en una carpeta, llamar a un servidor MCP. El resultado de cada llamada vuelve al modelo, y el agente guarda un registro de la conversación para que puedas retomarla. Si el resultado contiene AWS_ACCESS_KEY_ID=... porque el agente leyó un .env o ejecutó env, la clave está en el contexto del modelo y en el registro.

Hay por tanto dos copias que considerar. Una está en tu disco, en la carpeta de historial del agente. La otra está donde el proveedor del modelo procesa y puede conservar tus peticiones. Limpiar la primera no toca la segunda.

¿Dónde guarda cada agente su historial?

Claude Code

La documentación de datos de aplicación de Claude Code dice que los ficheros de ~/.claude están en texto plano y que todo lo que pasa por una herramienta se escribe en una transcripción en el disco: contenido de ficheros, salida de comandos y texto pegado. La conversación completa está en projects/<project>/<session>.jsonl, con cada mensaje, llamada a herramienta y resultado. Las transcripciones de subagentes tienen su propia carpeta, y las salidas grandes de herramientas se derivan a una carpeta tool-results/ junto a la sesión.

Claude Code borra estos ficheros cuando superan cleanupPeriodDays. El valor por defecto es 30 días y el mínimo es 1; la documentación indica que poner 0 da un error de validación. La página de uso de datos repite los 30 días por defecto para la caché local y remite a esa misma página para saber cómo borrarla. También señala que las transcripciones de sesiones iniciadas o continuadas por última vez en Claude Desktop o Cowork quedan exentas de ese límite por defecto.

Para acortar el plazo, pon un valor menor en ~/.claude/settings.json:

{
  "cleanupPeriodDays": 1
}

La misma página (almacenamiento en texto plano) enumera formas de conservar menos. Definir la variable de entorno CLAUDE_CODE_SKIP_PROMPT_HISTORY evita escribir transcripciones y el historial de prompts en cualquier modo. En modo no interactivo puedes pasar --no-session-persistence junto con -p. claude purge borra las transcripciones, la memoria y el historial de prompts que Claude Code guarda de un proyecto, después de mostrar el plan y pedir confirmación. Los ficheros son además ficheros normales, así que también puedes borrarlos tú.

El historial de prompts es un fichero aparte. ~/.claude/history.jsonl guarda cada prompt que escribiste, y la documentación dice que la limpieza por antigüedad no elimina esas entradas salvo que se aplique la configuración HIPAA. Una clave pegada en un prompt puede seguir ahí cuando las transcripciones ya no existen.

Codex CLI

La página de variables de entorno de OpenAI dice que CODEX_HOME fija la raíz del estado de Codex, que incluye configuración, credenciales, logs, sesiones, skills y metadatos del paquete, y que el valor por defecto es ~/.codex. La referencia de configuración tiene dos ajustes de historial: history.persistence («Control whether Codex saves session transcripts to history.jsonl», con los valores save-all o none) y history.max_bytes, que limita el tamaño del fichero de historial descartando las entradas más antiguas.

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

Para automatización, la referencia de comandos incluye codex exec --ephemeral: «Run without persisting session rollout files to disk».

Lo que no encontramos en las páginas que leímos: un periodo de retención para los ficheros de sesión, ni la estructura exacta de subcarpetas dentro de sessions. Si necesitas ese detalle, mira tu propia carpeta ~/.codex.

Cursor

La página de ayuda sobre privacidad de Cursor y su resumen de uso de datos describen lo que ocurre en el servidor, y ninguna dice dónde se guarda el historial de chat en tu ordenador ni cómo borrarlo. Es un hueco en lo que pudimos verificar, no una afirmación de que no se guarde nada. Revisa los ajustes de la propia aplicación para ver si hay controles de historial.

La parte del servidor sí está documentada. Con Privacy Mode activado, Cursor dice que tus datos no se usan para entrenar y que tiene acuerdos de retención cero con sus proveedores de modelos, con una excepción: si tus prompts o conversaciones activan detectores de abuso, los datos pueden almacenarse para investigación. Con Privacy Mode desactivado, el resumen dice que Cursor puede conservar y usar datos del código base, prompts, acciones del editor y fragmentos de código para mejorar sus funciones de IA. Las peticiones pasan por el backend de Cursor incluso si usas tu propia clave de API, y la página de ayuda dice que la retención cero no se aplica en ese caso: tus datos siguen la política de privacidad de tu proveedor, y Cursor guarda temporalmente en caché el contenido de ficheros en sus servidores para reducir la latencia. El resumen no da periodos de retención para el almacenamiento propio de Cursor.

OpenCode

La página de resolución de problemas de OpenCode indica las ubicaciones. Los logs están en ~/.local/share/opencode/log/. Los datos de sesión están en la carpeta project/ dentro de ~/.local/share/opencode/: en <project-slug>/storage/ si el proyecto está dentro de un repositorio Git, y en global/storage/ en caso contrario. En Windows la carpeta base es %USERPROFILE%\.local\share\opencode.

La documentación actual de OpenCode que pudimos abrir no describe cómo compartir sesiones ni un ajuste para ello. Si has compartido una sesión, consulta la ayuda de tu versión para saber cómo quitar el enlace.

No encontramos un periodo de retención documentado para los datos locales de sesión.

¿Suben los agentes la transcripción?

Para la llamada al modelo, sí, por diseño: el agente envía tus prompts y los resultados de las herramientas al proveedor del modelo, y así es como el modelo llega a ver una clave. Lo que el fabricante conserva después depende del producto y del plan.

En Claude Code, la página de uso de datos dice que los datos enviados incluyen todos los prompts del usuario y las salidas del modelo, cifrados en tránsito. La retención de Anthropic depende de la cuenta: en Free, Pro y Max, 5 años si permites el uso de datos para mejorar el modelo y 30 días si no; en Team, Enterprise y API, 30 días por defecto. La retención cero está disponible para Claude Code en Claude for Enterprise, y se activa por organización para cuentas que cumplan los requisitos.

Esa misma página enumera los casos en que una transcripción se envía a propósito. Ejecutar /feedback (y /bug o /share) envía una copia de tu historial de conversación, y esos informes se conservan 5 años. Si respondes Sí a la pregunta opcional «Can Anthropic look at your session transcript» que sigue a una encuesta de sesión, se sube la transcripción; los patrones conocidos de claves y tokens se ocultan antes de subirla, el resto del contenido no. Puedes desactivar el comando de feedback con DISABLE_FEEDBACK_COMMAND=1 y la encuesta con CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1.

En Codex CLI, las páginas de documentación que leímos no describen subidas de los ficheros de sesión locales, y no afirmamos qué conserva OpenAI en sus servidores. Eso depende de cómo inicies sesión y de tu plan, así que consulta las condiciones de OpenAI para tu cuenta. Para Cursor y OpenCode, mira las secciones anteriores.

¿Qué cambia zn-gate y qué no?

zn-gate es una capa local entre tu agente y las herramientas que usa. Cuando una herramienta devuelve salida, zn-gate sustituye los secretos que contiene, como claves de AWS, tokens de GitHub, JWT, claves privadas y contraseñas en URLs de bases de datos, por marcadores como __ZN_AWS_KEY_1__ antes de que el modelo vea el resultado. Como la transcripción registra lo que se mostró al modelo, una transcripción nueva contiene el marcador en lugar del valor. Un secreto pegado en un prompt se bloquea en lugar de enviarse.

En Claude Code, Codex CLI y OpenCode, zn-gate limpia la salida de las herramientas propias del agente. En Cursor, solo se limpia la salida de las herramientas MCP. La salida del shell y el contenido de los ficheros no se pueden reescribir ahí, así que los valores de ficheros que el agente lee, o que imprimen los comandos, pueden llegar al modelo.

Límites que conviene tener presentes, según el modelo de amenazas de zn-gate:

• No limpia las transcripciones escritas antes de instalarlo. Esos ficheros siguen conteniendo lo que tuvieran.
• No controla lo que un fabricante de agentes guarda en sus servidores. Reduce lo que se envía, y no puede recuperar lo enviado antes.
• Codex no puede reescribir la salida de las herramientas, así que zn-gate sustituye el resultado que ve el modelo. El registro de sesión propio de Codex en ~/.codex/sessions conserva la salida original.
• En Claude Code, la transcripción contiene la salida limpia de las herramientas, pero un prompt que zn-gate bloqueó queda en ella en claro, como dice la propia documentación de Claude Code. El comando mostrado en un diálogo de confirmación cuando zn-gate restaura un valor para un comando local también se registra ahí.
• OpenCode escribe la salida en vivo de un comando en ejecución antes de que zn-gate pueda verla, así que esa parte queda en la base de datos local de OpenCode.

¿Qué hacer si una clave puede estar ya en una transcripción?

1. Rota la clave. Crea una nueva en el proveedor y revoca la antigua. Borrar un fichero no deshace una copia enviada a un modelo o incluida en una copia de seguridad, por eso este paso va primero.

2. Encuentra las transcripciones que la contienen. Busca el prefijo de la clave en las carpetas de historial. Por ejemplo, en macOS o Linux:

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

   Sustituye AKIA por el prefijo de la clave que buscas. Usa un prefijo, no la clave entera, para que la clave no quede en el historial de tu shell.

3. Borra lo que no necesites. Elimina los ficheros de sesión que coincidan en las carpetas indicadas, o pon cleanupPeriodDays en un valor bajo en Claude Code y persistence = "none" en Codex. En Cursor, usa los controles de historial de la propia aplicación, ya que no encontramos una ruta documentada. En Claude Code, claude purge también elimina las líneas del proyecto en history.jsonl.

4. Revisa las otras copias. Mira las copias de seguridad, la sincronización en la nube de tu carpeta personal y cualquier sesión que hayas compartido. Si compartiste una sesión de OpenCode, quita el enlace como describe la ayuda de tu versión. En Claude Code, Anthropic conserva los informes de /feedback como se describió antes.

5. Evita copias nuevas. Saca los valores de los lugares que lee el agente y pon un depurador de secretos en el camino.

¿Cómo evito que nuevas claves lleguen a las transcripciones?

Instala zn-gate y mueve los valores de tu .env a su bóveda local. El fichero conserva marcadores, así que leerlo no muestra ningún valor:

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

init pide confirmación antes de cada cambio y configura Claude Code, Codex CLI, Cursor y OpenCode donde los encuentre. unlock crea la bóveda la primera vez. env shadow sustituye los valores reales de .env por marcadores como __ZN_STRIPE_KEY__ y guarda una copia cifrada que zn env unshadow puede restaurar. check prueba la protección con un secreto falso en una carpeta temporal y te dice qué agente no está protegido. Para los detalles de la configuración, consulta cómo evitar que Claude Code, Codex CLI, Cursor y OpenCode lean tu .env con un solo comando.

¿Qué no cubre esta guía?

• Las rutas y los ajustes cambian entre versiones de cada agente. Lo anterior procede de la documentación de los fabricantes en el momento de escribir, y la estructura de ficheros dentro de cada carpeta puede ser distinta en tu versión.
• No probamos el borrado en cada plataforma ni verificamos qué hacen los fabricantes con los datos borrados en sus servidores.
• Las sesiones en la nube, los productos de chat y otros editores quedan fuera. zn-gate no cubre las sesiones de Claude Code en la nube, Cowork ni el chat.
• Un depurador de secretos trabaja con los formatos que reconoce. Un secreto en un formato que no conoce puede pasar, y por eso rotar es el primer paso tras una fuga.

Preguntas frecuentes

¿Los agentes de código guardan mis claves de API en su historial de conversaciones?

Pueden hacerlo. La documentación de Claude Code dice que todo lo que pasa por una herramienta se escribe en una transcripción en texto plano en el disco, incluido el contenido de ficheros y la salida de comandos. Codex CLI documenta que guarda los ficheros de sesión bajo CODEX_HOME, y OpenCode documenta una carpeta local de sesiones. Las páginas de Cursor que leímos no dicen dónde se guarda el historial de chat en local.

¿Dónde guarda Claude Code sus transcripciones y durante cuánto tiempo?

En ~/.claude/projects/, con un fichero .jsonl por sesión. Claude Code las borra pasados cleanupPeriodDays días: 30 por defecto, con un mínimo de 1.

¿Cómo evito que Codex CLI guarde el historial?

Pon persistence en none dentro de la tabla [history] de config.toml para dejar de escribir history.jsonl, y ejecuta codex exec con --ephemeral para que una ejecución no interactiva no escriba ficheros de sesión. La documentación no indica un periodo de retención para los ficheros de sesión interactivos.

¿zn-gate limpia las transcripciones que ya existen?

No. zn-gate sustituye los secretos de la salida de las herramientas por marcadores antes de que el modelo los vea, así que las transcripciones nuevas contienen marcadores en lugar de valores. No reescribe los ficheros escritos antes de instalarlo y no controla lo que el fabricante del agente guarda en sus servidores.

¿Qué hago si una clave llegó a una transcripción?

Rótala primero en el proveedor, porque borrar un fichero no deshace una copia enviada a un modelo o incluida en una copia de seguridad. Después borra las transcripciones que la contienen y mueve los valores de tu .env a la bóveda con npx -y zn-gate env shadow .env.

¿zn-gate protege Cursor igual que los otros agentes?

No del todo. En Cursor, zn-gate limpia solo la salida de las herramientas MCP. La salida del shell y el contenido de los ficheros no se pueden reescribir ahí, así que saca los valores de los ficheros con npx -y zn-gate env shadow .env. Un secreto pegado en un prompt se bloquea en los cuatro agentes.

---

Para probarlo en tus propios agentes, ejecuta npx -y zn-gate init (MIT, local, sin cuenta) y después npx -y zn-gate check. El código está en GitHub y las guías para cada agente empiezan en Instalación. Las rutas que puede usar un comando de shell para llegar a un fichero protegido están en cómo un agente de código podría leer tu .env de forma indirecta.