Un archivo de configuración de Claude Code apareció en 1.122 copias públicas de GitHub con al menos una contraseña, token o clave, según la investigación de Apiiro. El asistente puede guardar literalmente un comando de shell cuando el usuario elige «Yes, and don’t ask again»; si el comando contiene una credencial y el archivo se publica, esa credencial queda expuesta.
Apiiro identificó 1.379 secretos distintos en esas copias de .claude/settings.local.json. La empresa no comprobó si seguían funcionando todos, pero una organización a la que avisó confirmó que su clave todavía estaba activa. El recuento ampliado, que incorpora historial de Git, archivos de configuración compartidos y registros de conversaciones de agentes, asciende a 2.539 secretos en 1.994 repositorios.
Qué guarda Claude Code al recordar un permiso
Claude Code suele pedir autorización antes de ejecutar comandos de shell. Al aceptar «Yes, and don’t ask again», el usuario crea una regla que permite ejecutar de nuevo comandos coincidentes sin volver a preguntar. La documentación de Claude Code indica que esa aprobación se almacena en el archivo local del proyecto, .claude/settings.local.json.
La regla conserva lo que se aprobó. A veces se trata de un patrón, como npm test *; otras, de un comando concreto. En este último caso, si alguien escribió una contraseña o un token directamente en el comando, el valor puede quedar guardado en texto plano junto con la regla. Los investigadores de Apiiro reprodujeron el comportamiento con los modelos Opus 5.5 y Fable 5.1.
El archivo está pensado para ajustes personales de un proyecto, no para compartirlo con el equipo. Claude Code intenta mantenerlo fuera de Git: cuando lo crea por primera vez dentro de un repositorio, lo añade al archivo global de exclusiones de Git del usuario. Esa protección se aplica a los repositorios de esa persona en ese equipo, pero no se incorpora a la configuración del proyecto.
La exclusión global tampoco retira archivos que ya se habían añadido al control de versiones. Apiiro señala que Claude Code no incluye automáticamente .claude/settings.local.json en el .gitignore del proyecto. Por eso la regla no acompaña al repositorio y no protege a otros colaboradores ni a otros equipos. La documentación de Anthropic también indica que, si el usuario crea el archivo manualmente, debe añadirlo por su cuenta a .gitignore.
La diferencia entre un archivo local y uno compartido importa: .claude/settings.json es la configuración de proyecto que un equipo puede versionar deliberadamente, mientras que .claude/settings.local.json está destinado a las preferencias personales de una persona para ese proyecto. Apiiro encontró secretos también en el archivo compartido, pero en una proporción menor.
1.379 secretos en las copias públicas
Apiiro localizó 104.185 copias de .claude/settings.local.json en 103.617 repositorios públicos de GitHub. De ellas, 1.122 —alrededor del 1,1%— contenían al menos un secreto. Para clasificar un valor como tal, los investigadores comprobaron si coincidía con formatos conocidos de claves o si una contraseña o un token aparecía junto a la dirección de un servidor público. Un revisor basado en IA también debía respaldar la clasificación.
Más de un tercio de los secretos daba acceso directo a bases de datos. El conjunto incluía 379 contraseñas de bases de datos, 43 credenciales SSH de servidores públicos, 42 tokens de GitHub, GitLab y npm, y 23 claves de AWS. Apiiro también señaló ejemplos de especial impacto: una clave en la nube con permisos de administrador perteneciente a un proveedor de bases de datos y la contraseña propietaria de una base de datos de historiales médicos.
Los archivos pertenecían a 63 organizaciones, en su mayoría empresas de software de distintos tamaños. Según Apiiro, el día en que hizo el recuento todos los archivos con secretos seguían presentes en la rama predeterminada de sus repositorios. En la mitad de esos repositorios, llevaban allí al menos 217 días.
El historial de Git añade otras exposiciones que ya no aparecen en la versión actual: Apiiro encontró 734 secretos adicionales en versiones antiguas de archivos de 509 repositorios. A menudo, el archivo ya había sido eliminado, pero el secreto seguía en el historial. También localizó 211 forks de 74 repositorios que conservaban los mismos secretos que los originales.
El recuento más amplio incluye 298 copias de .claude/settings.json con secretos, entre 76.011 archivos compartidos. Apiiro sumó además el historial antiguo y los registros de conversación de agentes para llegar a 2.539 secretos distribuidos en 1.994 repositorios.
El historial de avisos y los límites de la investigación
La exposición no era una conducta recién detectada. Un informe de errores de Claude Code presentado el 11 de agosto de 2025 ya advertía que los comandos aprobados con claves API y tokens se guardaban palabra por palabra en settings.local.json. Un bot cerró ese aviso el 3 de enero por falta de actividad durante 60 días. iTWire recoge que el cierre fue una acción automática de mantenimiento, no una resolución técnica.
Apiiro afirma que los cuatro avisos relacionados que cita fueron cerrados por el mismo bot; el más reciente, el día anterior a la publicación de su investigación. Según la empresa, Anthropic no respondió a ninguno. Por separado, la firma de seguridad ironPeak describió en febrero de 2026 que había encontrado comandos aprobados con contraseñas de bases de datos y claves API en un archivo de configuración de Claude que se había enviado al repositorio. También publicó una herramienta para buscar secretos en archivos de configuración de agentes y en su historial.
Apiiro recopiló datos públicos de GitHub entre el 1 y el 3 de noviembre, según iTWire. La clasificación combina formatos y contexto con una revisión de IA; no es una comprobación independiente de que cada credencial sea válida. Los investigadores tampoco probaron las claves encontradas ni determinaron si alguien las había utilizado. La empresa sí comunicó que avisó a organizaciones afectadas el 2 y el 3 de noviembre, y que una de ellas confirmó que su clave expuesta seguía activa.
En 539 de los 1.105 repositorios que Apiiro pudo rastrear, un commit que incluía a Claude como coautor modificó el archivo. Ese dato no demuestra que Claude introdujera o publicara todas las credenciales; sí muestra que las modificaciones del archivo podían formar parte de commits atribuidos al asistente.
Apiiro comparó la documentación de 16 agentes de programación y confirmó que Claude Code era el único que, por defecto, guardaba el comando aprobado completo en un archivo del proyecto. Esa comparación se refiere a la conducta documentada que analizaron los investigadores, no a una prueba de que los demás agentes no puedan exponer secretos de otras formas.
Rotar las credenciales antes de limpiar Git
La recomendación central de Apiiro es cambiar primero todas las contraseñas, tokens y claves que hayan aparecido en esos archivos, y ocuparse después de la limpieza. Borrar el archivo actual no elimina las versiones anteriores de Git, los forks ni las copias que otras personas hayan descargado. La rotación reduce el riesgo de que una credencial expuesta siga dando acceso mientras se revisan esas copias.
Para localizar el problema, Apiiro recomienda buscar .claude/settings.local.json y .claude/settings.json en toda la organización, y revisar el historial de cada repositorio aunque el archivo ya no esté presente. También aconseja dejar de seguir el archivo local con git rm --cached .claude/settings.local.json, añadirlo al .gitignore del repositorio y eliminar de la copia local cualquier regla que contenga un secreto.
La empresa recomienda no escribir credenciales literales en los comandos. Una regla puede hacer referencia a una variable como $DB_URL en vez de guardar el valor secreto; también propone autorizar patrones de comandos en lugar de comandos únicos. iTWire advierte que asignar la contraseña literalmente dentro de una asignación de variable en línea seguiría dejando el valor dentro del texto guardado.
La búsqueda no debería limitarse a GitHub. Apiiro señala que el archivo es JSON sin cifrar y puede acabar dentro de un paquete npm, una imagen Docker, un archivo ZIP o una carpeta sincronizada. También recomienda tratar directorios de agentes como .claude/, .cursor/, .gemini/ y .specstory/, además de sus archivos de memoria, como posibles contenedores de secretos en equipos y repositorios.
Las herramientas habituales de detección tampoco encontraron todos los casos. Apiiro ejecutó gitleaks y TruffleHog sobre las copias sin usar el paso de verificación de esas herramientas. Gitleaks señaló 564 de los 1.122 archivos con secretos y TruffleHog, 643; ninguna de las dos detectó 215. Según los investigadores, muchos fallos corresponden a contraseñas incrustadas en comandos: expresiones como PGPASSWORD=, sshpass -p o mysql -p pueden parecer texto ordinario en vez de una clave con formato reconocible.
Para los equipos de seguridad, Apiiro propone incorporar estos archivos a los análisis de secretos en pre-commit y CI, incluir el historial de Git y comprobar que el escáner detecte contraseñas dentro de comandos, no solo claves con formatos conocidos. También recomienda añadir el archivo local de Claude Code a las plantillas organizativas de .gitignore y revisar primero las credenciales asociadas a servidores públicos.
El antecedente del gusano Shai-Hulud muestra por qué Apiiro pide revisar también los equipos de desarrollo: en septiembre de 2025, ese malware ejecutó TruffleHog en ordenadores infectados y el escáner marcó más de la mitad de los archivos como secretos. La investigación actual no establece que las credenciales de Claude Code hayan sido utilizadas. Sí documenta que, al menos en un caso notificado, una clave seguía activa.
Fuentes: The Hacker News, Claude Code Docs, iTWire, NEXSIGHT CYBER WIRE
