Claude Code guarda contraseñas en un archivo que acaba en GitHub: miles de secretos expuestos

En 30 segundos

• Al aprobar un comando con «Sí, y no volver a preguntar», Claude Code guarda el comando completo, credenciales incluidas, en .claude/settings.local.json.
• Apiiro encontró 1,122 copias públicas de ese archivo con al menos un secreto; contando historial y otros archivos, 2,539 secretos en 1,994 repositorios.
• Es un riesgo de exposición, no una brecha probada: Apiiro no verificó si las claves seguían activas, aunque una empresa confirmó que la suya sí.

Los agentes de programación que trabajan desde la terminal piden permiso antes de ejecutar comandos. Para no repetir la pregunta, Claude Code, la herramienta de Anthropic, ofrece una opción de aprobación permanente. El problema, según una investigación de la firma de seguridad Apiiro publicada a principios de noviembre, es dónde y cómo se guarda esa aprobación.

Qué encontraron

Cuando un desarrollador elige «Yes, and don’t ask again» («Sí, y no volver a preguntar») para un comando de terminal, Claude Code escribe una regla de permiso en el archivo .claude/settings.local.json del proyecto. Esa regla conserva el texto íntegro del comando. Si el comando llevaba una contraseña, un token o una cadena de conexión, queda ahí en texto plano. Y si el archivo se sube a un repositorio público, cualquiera puede leerlo.

Los investigadores Shmulik Cohen y Matan Giladi rastrearon GitHub entre el 1 y el 3 de noviembre, según iTWire.

Archivos analizados104,185copias públicas del archivo local

Con secretos1,122≈ 1.1 %; 1,379 valores distintos

Total de secretos2,539en 1,994 repos, con historial y otros archivos

Claves confirmadas activas1Apiiro no probó las demás

Las cifras miden cosas distintas. Las 1,122 copias son archivos locales que, en su versión actual, contienen al menos un secreto. El total de 2,539 suma además secretos que solo sobreviven en el historial de git, en el archivo compartido .claude/settings.json y en transcripciones del agente. Entre lo hallado, según el resumen de la Cloud Security Alliance (CSA), hay 379 contraseñas de bases de datos, 43 accesos SSH a servidores públicos y 23 claves de AWS.

Apiiro notificó a las organizaciones afectadas y una confirmó que su clave seguía funcionando. Del resto no se sabe. Los investigadores también detectaron que, en 539 de 1,105 repositorios rastreados, un commit coescrito por Claude modificó el archivo, lo que, como subraya iTWire, no prueba que el agente introdujera cada credencial.

Otro hallazgo incómodo: según la CSA, los escáneres populares gitleaks y TruffleHog no detectaron 215 de los archivos, sobre todo porque las contraseñas estaban dentro de la sintaxis del comando, como PGPASSWORD= o mysql -p.

Por qué Claude Code y no otros

Apiiro comparó la documentación de 16 agentes de programación y, según la CSA, Claude Code fue el único confirmado que guarda por defecto el comando aprobado completo en un archivo del proyecto. No es un caso aislado de GitHub: en abril, Check Point ya había encontrado este mismo archivo con credenciales dentro de paquetes publicados en npm.

Tampoco es una idea nueva para Anthropic. Un reporte en el repositorio de Claude Code describió el comportamiento en agosto de 2025 y se cerró de forma automática en enero de 2026, sin respuesta de los mantenedores, según la CSA e iTWire.

1. 11 ago 2025
   Primer aviso público

   Un usuario reporta el problema en GitHub.

2. 3 ene 2026
   Cierre automático

   El reporte se cierra como «no planeado».

3. Abr 2026
   Check Point y npm

   Credenciales en paquetes que incluían el archivo.

4. 1–3 nov
   Rastreo de Apiiro

   Notifica a las empresas afectadas.

5. 5–6 nov
   Se publica la investigación

   La retoman medios y la CSA.

Qué dice Anthropic

No encontramos una respuesta pública de Anthropic a la investigación. Su documentación sí describe una protección: la primera vez que Claude Code escribe ese archivo en un repositorio git, añade una exclusión al archivo global de exclusiones de git del desarrollador. El límite, señalan iTWire y la CSA, es que esa regla vive solo en la máquina de quien la generó: no viaja con el proyecto, no protege a compañeros ni servidores de integración continua y no sirve si el archivo ya estaba versionado.

Variables de entorno: no basta

Escribir PGPASSWORD=... delante del comando no resuelve nada: la asignación forma parte del texto aprobado y se guarda igual. Lo recomendable es referenciar la credencial desde un gestor de secretos o una variable ya definida, sin escribir el valor literal.