Una investigación de la empresa de seguridad Apiiro ha encontrado 1.122 ficheros de configuración de Claude Code publicados en GitHub con contraseñas, claves de la nube y tokens de API en texto plano. El origen es una opción pensada para ahorrar clics, «Yes, and don’t ask again», que guarda el comando aprobado tal cual, secretos incluidos. Más allá del fallo concreto, el caso pone el foco en un problema que comparten todos los agentes de programación: dónde y cómo recuerdan lo que el usuario les ha permitido hacer.
Las claves del fallo de permisos de Claude Code en 30 segundos
- Al aprobar un comando con «don’t ask again», Claude Code lo guarda literal en
.claude/settings.local.json. - Apiiro halló 104.185 copias públicas de ese fichero; 1.122 con secretos válidos.
- Los escáneres Gitleaks y TruffleHog pasaron por alto 215 de esos ficheros.
- Anthropic estudia un escáner de secretos integrado y cambios en la gestión de permisos, sin fecha.
Los detalles técnicos de la filtración, las cifras completas y los pasos para revisar un repositorio están en el análisis publicado por OpenSecurity sobre los secretos que Claude Code ha dejado en GitHub. Aquí interesa otra pregunta: por qué una función tan inocente acaba exponiendo credenciales de empresas, y qué dice eso de cómo se están diseñando los agentes.
La fatiga de aprobar y la memoria del agente
Un agente de programación que ejecuta comandos en la terminal necesita un sistema de permisos, y cualquier sistema de permisos que pregunte demasiado acaba siendo ignorado. Es la llamada fatiga de aprobación: tras la vigésima confirmación, el usuario pulsa lo que haga desaparecer el aviso. «Yes, and don’t ask again» existe para eso, y tiene sentido para comandos como ejecutar los tests o compilar.
El problema está en lo que se recuerda. Según Apiiro, la regla que se guarda es la cadena exacta del comando. Si el agente propuso conectarse a una base de datos con la contraseña escrita en línea y el usuario lo aprobó para siempre, la contraseña pasa a formar parte de la configuración del proyecto. El fichero está pensado para quedarse en el equipo del desarrollador, y Claude Code lo añade a la lista global de exclusiones de Git. Pero esa protección depende de la máquina, no del repositorio, y falla cuando el proyecto se clona en otro equipo o la carpeta se convierte después en repositorio. En algunos casos documentados fue el propio Claude Code el que hizo commit del fichero.
Hay un matiz importante: el comando que se aprueba no siempre lo ha escrito el usuario, porque a menudo lo propone el propio agente. Cuando la IA genera código y comandos a gran velocidad, una mala práctica de siempre, como pasar secretos por la línea de comandos, puede repetirse sin que nadie se fije. Y los escáneres tradicionales tampoco están preparados: Gitleaks y TruffleHog no detectaron 215 de los 1.122 ficheros con credenciales, porque una contraseña dentro de un comando no siempre tiene el patrón de una clave reconocible.
Qué propone Anthropic y qué queda pendiente
Boris Cherny, responsable de Claude Code, ha explicado que el equipo estudia un escáner de secretos integrado y cambios en cómo la herramienta maneja los permisos de comandos, y recomienda mientras tanto usar escáneres y mantener la configuración local fuera de los repositorios. No hay fecha para esos cambios. Algunas coberturas apuntan además a que Anthropic sugiere el modo automático de permisos como alternativa a acumular aprobaciones manuales.
Conviene tener presente que Apiiro es un proveedor comercial de seguridad de aplicaciones y que sus cifras proceden de su propio análisis. También que el problema no es exclusivo de Claude Code en su planteamiento: cualquier agente que guarde aprobaciones persistentes en ficheros del proyecto puede caer en algo parecido si almacena el comando completo en lugar de un patrón o una referencia al secreto. Es el mismo terreno en el que se mueven herramientas que intentan poner límites a los agentes que programan, como brakes y sus frenos mecánicos para el código.
Para quien use Claude Code hoy, lo práctico es revisar si .claude/settings.local.json está en algún repositorio, cambiar cualquier credencial que aparezca en él (borrar el fichero no la elimina del historial de Git ni de los forks), añadirlo al .gitignore de cada proyecto y usar variables de entorno o gestores de secretos en lugar de escribir contraseñas en los comandos.
Preguntas frecuentes
¿Qué hace la opción «Yes, and don’t ask again» de Claude Code?
Guarda una regla de permiso en .claude/settings.local.json para que Claude Code ejecute ese comando sin volver a preguntar. Según Apiiro, la regla incluye el comando literal, con sus secretos.
¿Cuántos ficheros con secretos se han encontrado?
1.122 de las 104.185 copias públicas del fichero que Apiiro localizó en GitHub.
¿Afecta a otros agentes de programación?
Las cifras de Apiiro se refieren a Claude Code, pero cualquier agente que guarde aprobaciones con el comando completo en ficheros del proyecto podría tener un riesgo similar.
Fuentes:
