La función «No volver a preguntar» de Claude Code filtra secretos en repositorios públicos

Las contraseñas y las claves API introducidas en comandos de shell aprobados mediante Claude Code, el asistente de Anthropic, quedan expuestas en repositorios públicos de GitHub. La firma de seguridad Apiiro informó el 6 de noviembre de 2026 que el asistente de IA guarda estas credenciales en texto plano cuando los usuarios seleccionan la opción "Sí, y no volver a preguntar".

Qué ocurrió

Cuando los desarrolladores utilizan Claude Code, el asistente solicita permiso antes de ejecutar comandos de shell. Si un usuario opta por aprobar permanentemente un comando específico, la herramienta guarda la cadena exacta del comando, incluidos los secretos incrustados, en un archivo de configuración local llamado .claude/settings.local.json. Aunque la herramienta intenta excluir este archivo del control de versiones añadiéndolo a los excluidos globales de git del usuario, no lo incluye en el .gitignore del proyecto. En consecuencia, si el archivo se confirma manualmente o por el propio agente, pasa a formar parte del historial del repositorio.

Apiiro escaneó repositorios públicos de GitHub e identificó 104.185 copias de este archivo de configuración en 103.617 repositorios. De estos, 1.122 archivos contenían al menos un secreto, sumando un total de 1.379 credenciales únicas expuestas. Los datos filtrados incluyen 379 contraseñas de bases de datos, 43 credenciales de inicio de sesión SSH para servidores públicos, 42 tokens para servicios como GitHub y npm, y 23 claves de AWS. Los investigadores confirmaron que una empresa notificada tenía una clave activa expuesta a través de este mecanismo.

La exposición es persistente porque eliminar el archivo de la rama actual no borra su presencia en el historial de git ni en las bifurcaciones (forks). En 539 de los repositorios rastreados, los commits que listaban a Claude como coautor modificaron el archivo, lo que sugiere que el agente suele confirmar sus propios cambios de configuración. Además, 298 copias del archivo compartido .claude/settings.json, que los equipos confirman intencionadamente, también contenían secretos. Al incluir versiones históricas y registros de chat del agente, el número total de secretos expuestos asciende a 2.539 en 1.994 repositorios.

Cómo funciona

La vulnerabilidad surge de cómo Claude Code gestiona la aprobación de comandos. Por defecto, solicita a los usuarios antes de ejecutar comandos de shell. Cuando un usuario selecciona "Sí, y no volver a preguntar", el sistema crea una regla de permitidos en .claude/settings.local.json. Esta regla coincide con futuros comandos para evitar solicitudes repetidas. Si el comando aprobado es una cadena exacta en lugar de un patrón, cualquier contraseña o token escrito en ese comando se guarda literalmente en el archivo JSON.

Aunque Claude Code añade el archivo a los excluidos globales de git del usuario en su primera creación dentro de un repositorio, esta protección es local a esa máquina y usuario específicos. No se propaga a otros colaboradores ni protege contra confirmaciones accidentales. Además, las herramientas estándar de escaneo de secretos suelen pasar por alto estas fugas. En pruebas, gitleaks solo marcó 564 de los 1.122 archivos expuestos, y TruffleHog marcó 643. Ambas herramientas omitieron por completo 215 archivos porque buscan formatos de clave conocidos, mientras que las contraseñas incrustadas en comandos como mysql -p aparecen como texto ordinario.

Detalles clave

• Apiiro encontró 1.122 copias públicas de .claude/settings.local.json que contenían al menos un secreto.
• Los secretos expuestos incluyen 379 contraseñas de bases de datos, 43 inicios de sesión SSH y 23 claves de AWS.
• Claude Code es el único agente de codificación entre los 16 revisados que se confirmó que guarda comandos aprobados completos en archivos de proyecto por defecto.
• Escáneres estándar como gitleaks y TruffleHog no detectaron 215 de los secretos expuestos.
• Cuatro informes de errores sobre este comportamiento fueron cerrados por un bot automatizado sin respuesta de Anthropic.
• Los secretos siguen siendo accesibles en el historial de git y en las bifurcaciones incluso después de borrar el archivo de la rama principal.

Por qué importa

Para los ingenieros de software, este incidente destaca una brecha crítica en el modelo de seguridad de los asistentes de codificación con IA. Los desarrolladores a menudo asumen que los archivos de configuración locales están a salvo de la exposición pública, especialmente cuando las herramientas afirman gestionar exclusiones de git. Sin embargo, la dependencia de la configuración global de git significa que cualquier colaborador que confirme el archivo, o cualquier error en la configuración local, puede filtrar datos sensibles. El hecho de que el propio agente de IA pueda confirmar estos archivos agrava el riesgo, ya que los desarrolladores podrían no revisar cada cambio realizado por el asistente.

Los equipos de seguridad deben tratar ahora las carpetas específicas del agente y los archivos de memoria con el mismo escrutinio que los archivos .env. El fallo de las herramientas de escaneo estándar para detectar contraseñas incrustadas en cadenas de comandos significa que las tuberías CI/CD existentes pueden ofrecer una falsa sensación de seguridad. Las organizaciones necesitan actualizar sus hooks pre-commit y configuraciones de escaneo de secretos para apuntar específicamente a estos nuevos vectores, asegurando que las contraseñas dentro de los comandos sean marcadas junto con los formatos tradicionales de claves API.

Qué puedes hacer

• Busca en tu organización de GitHub .claude/settings.local.json y .claude/settings.json, incluyendo en el historial de git.
• Rota cada contraseña, token y clave que haya sido almacenada alguna vez en estos archivos antes de intentar limpiarlos.
• Ejecuta git rm --cached .claude/settings.local.json y añade el archivo al .gitignore de tu repositorio.
• Inspecciona manualmente el archivo de configuración local en tu máquina y elimina cualquier regla que contenga secretos codificados.
• Usa variables de entorno (por ejemplo, $DB_URL) en los comandos en lugar de escribir secretos directamente, para que la regla guardada haga referencia al nombre de la variable.
• Aprueba patrones de comandos (por ejemplo, npm run:*) en lugar de comandos únicos exactos para evitar guardar argumentos específicos.