Claude Code filtra contraseñas en GitHub: Apiiro halla secretos en 1100 archivos de configuración

Lanzas Claude Code, te propone ejecutar un comando de shell y, para no distraerte, pulsas «Yes, and don't ask again». Cómodo. Pero junto con la comodidad puedes escribir sin darte cuenta la contraseña de tu base de datos en el proyecto. Según los investigadores de Apiiro, eso es exactamente lo que ocurre en miles de repositorios.

Cómo llega un secreto al archivo

El mecanismo es sencillo. Cuando el usuario permite un comando de forma permanente, Claude Code guarda esa decisión como una regla en el archivo local .claude/settings.local.json. A veces la regla se escribe como un patrón. Pero a menudo el comando llega al archivo tal cual, con todo lo que lleva dentro.

Imagina un ejemplo típico: le pides al agente que revise la base de datos y ejecuta psql con una cadena de conexión donde la contraseña aparece en texto plano. O lanza curl con un token de API en una cabecera. Apruebas el comando «para siempre» y toda la cadena con el secreto queda en un archivo JSON.

Mientras el archivo permanezca en tu máquina, es tolerable (si no hackean la máquina). Anthropic indica en su documentación que este archivo se añade al .gitignore global del desarrollador. Pero el .gitignore global vive en tu ordenador, no en el repositorio. Si clonas el proyecto en otra máquina, conviertes la carpeta en repositorio más tarde o trabajas en equipo, la protección desaparece. Apiiro también señala que en muchos casos Claude Code hace por sí mismo commit de los cambios en este archivo sin intervención del usuario.

La escala y por qué los escáneres no bastan

Los analistas de Apiiro encontraron más de 100 000 casos en los que el archivo local de configuración de Claude Code acabó en un repositorio público de GitHub. La mayoría son inofensivos. Pero en unos 1100 archivos de 63 organizaciones aparecieron secretos reales: tokens de API, contraseñas de bases de datos, claves privadas e incluso credenciales de root.

Eliminar el archivo del repositorio no basta. Si el proyecto ya se ha bifurcado (fork), los secretos permanecen en los forks. Así que una clave debe considerarse comprometida en cuanto haya aparecido una sola vez en un commit público.

También es desagradable que los escáneres de secretos habituales no garanticen protección. De los ~1100 secretos encontrados, 215 no los detectaron ni gitleaks ni TruffleHog. La razón es clara: el secreto está integrado en la cadena del comando, y no en el formato habitual KEY=value.

El historial tampoco inspira confianza. Se avisó del problema en informes de errores ya en agosto de 2025. Otros informes mencionaban que el archivo a veces no entraba en .gitignore y que los comandos sensibles podían escribirse en otro archivo, sin ninguna protección. Todos estos avisos se cerraron sin acción tras 60 días de inactividad.

El fin de semana, en un hilo de Hacker News, Boris Cherny, del equipo de Claude Code, respondió que el equipo «está estudiando qué se puede hacer». Según él, estos archivos casi nunca deberían acabar en git, y los casos problemáticos surgen cuando los archivos se crearon y se subieron manualmente. Recomendó el auto mode, donde los clasificadores deciden por sí mismos qué solicitudes de permisos son rutinarias. Cuando otro usuario señaló que en auto mode también pueden guardarse comandos sensibles en la configuración, Cherny reconoció: «buen hallazgo». En el equipo consideran un escáner de secretos integrado en Claude Code como una posibilidad de futuro.

Qué hacer hoy

No conviene esperar un parche. Esta es una lista breve para desarrolladores y líderes de equipo:

• Añade .claude/settings.local.json al .gitignore del propio repositorio, no solo al global.
• Revisa el historial: git log --all -- .claude/settings.local.json. Si el archivo se subió alguna vez, ábrelo y busca contraseñas y tokens.
• Regenera todo lo que encuentres. Borrar el archivo no revoca la clave, sobre todo si hay forks.
• No incluyas secretos en los comandos que apruebas «para siempre». Usa variables de entorno o un gestor de secretos.
• Activa un escáner de secretos pre-commit y no lo consideres una panacea: los 215 fallos demuestran que una sola herramienta no basta.
• Revisa el propio archivo de configuración antes de hacer push. Es JSON normal y es fácil ver lo que sobra.

No es la primera vez que un agente de IA expone datos por accidente. El mes pasado Meta suspendió la función de compartir en su agente Muse: los investigadores descubrieron que los enlaces a los materiales compartidos eran fáciles de adivinar.

La lección vale para cualquier herramienta de agentes. Todo lo que el agente recuerda por tu comodidad se convierte en un archivo más que alguien puede publicar por accidente. Trata las configuraciones de los agentes con el mismo rigor que el .env.