Claude Code apunta tus contraseñas

Un atajo para no aprobar cada orden

Claude Code pide permiso antes de ejecutar la mayoría de comandos. Para no aprobar lo mismo una y otra vez, ofrece la respuesta «Yes, and don't ask again» («Sí, y no volver a preguntar»).

Según la documentación de Anthropic, esa respuesta guarda la aprobación como una regla allow en el fichero .claude/settings.local.json del proyecto. El problema, según Apiiro, aparece cuando la regla registra el comando exacto en vez de un patrón: cualquier contraseña escrita en esa orden queda guardada con ella, en texto plano.

Apiiro lo encontró en más de mil repositorios

Apiiro compartió su investigación con Anthropic antes de publicarla. Sus cifras las recoge iTnews, medio australiano de tecnología para profesionales.

Según Apiiro, el fallo se reproduce con Opus 5.5 y Fable 5.1, los modelos actuales de Anthropic, y es una propiedad de Claude Code, no del modelo. Según Apiiro, en GitHub público hay 104.185 copias del fichero repartidas en 103.617 repositorios.

Más de un tercio abría una base de datos

Según Apiiro, 1.122 de esas copias contenían al menos un secreto real, 1.379 distintos en total, y más de un tercio daba acceso directo a una base de datos. Según Apiiro, en el desglose figuran claves de rol de servicio de Supabase, un servicio de bases de datos; accesos SSH a servidores públicos, algunos con la contraseña de root, y claves de Amazon Web Services (AWS).

Según Apiiro, si se suman las versiones antiguas del fichero, el fichero de configuración compartido que los equipos suben a propósito y las transcripciones guardadas de conversaciones con el agente, el recuento llega a 2.539 secretos en 1.994 repositorios.

Al menos una clave seguía activa

Según Apiiro, que no comprobó si las credenciales seguían funcionando, una organización a la que avisó confirmó que su clave estaba activa. La mayoría de los ficheros eran de desarrolladores individuales, pero según Apiiro también había 63 organizaciones afectadas.

Entre ellas, según Apiiro, una empresa de bases de datos con su propia clave de API en la nube con acceso de gestión, una agencia de software con un token de producción y la contraseña de propietario de la base de datos en la nube de una aplicación de historias clínicas.

Los escáneres dejan pasar 215 ficheros

Según Apiiro, de los 1.122 ficheros con secreto, 215 no los detectó ni gitleaks ni TruffleHog.

El riesgo no acaba en GitHub: el fichero queda en formato JSON y en texto plano en el ordenador del desarrollador. El gusano Shai-Hulud, que se propagaba por el registro de paquetes npm, ya pasó TruffleHog por los ficheros de sus víctimas en septiembre de 2025.

El problema tampoco es nuevo. Usuarios de Claude Code lo señalaban en GitHub desde agosto de 2025, y en abril de 2026 Lakera, propiedad de la empresa de ciberseguridad Check Point, encontró credenciales en 33 de esos ficheros dentro de 30 paquetes publicados en npm.

Anthropic estudia cómo evitarlo

Boris Cherny, responsable de Claude Code en Anthropic, respondió en Hacker News, el foro de Y Combinator: «Hasta ahora Claude Code no ha limpiado secretos (hay muchas buenas herramientas para eso), pero estamos estudiando qué podemos hacer para evitarlo».

Según Cherny, el equipo planea probar que el modo automático detecte esos comandos y un escaneo básico de secretos, aunque podría no bastar. Cuando un lector le señaló que en el modo automático podía pasar lo mismo, respondió: «Sí, bien visto».

Cherny sostiene que, como Claude Code excluye el fichero de git al crearlo, las copias expuestas se crearon o se subieron a mano. La documentación de Anthropic describe ese comportamiento: la primera vez que Claude Code escribe el fichero, lo añade a las exclusiones globales de git, y si alguien lo creó a mano debe añadirlo él mismo al .gitignore. Cherny recomienda el modo automático en vez de las reglas de permiso, junto al escaneo de secretos que ofrecen GitHub y otros servicios.

Primero se cambian las claves y luego se limpia el fichero

Apiiro recomienda cambiar todas las credenciales que haya contenido el fichero antes de limpiarlo, porque borrarlo deja los secretos en el historial de git, en las bifurcaciones y en los clones. Después, dejar de seguir el fichero y añadirlo al .gitignore de cada repositorio, usar variables de entorno en vez de escribir secretos en los comandos y aprobar patrones en lugar de comandos literales.