Claude Code dejó secretos en 1122 archivos públicos de GitHub por culpa de «Don't ask again»

Le pides al agente que llame a una API, te pide permiso para ejecutar el comando, estás cansado de pulsar «Yes» por décima vez y eliges «Don't ask again». Cómodo. Pero Qodo descubrió que este botón tiene un efecto secundario: en 1122 archivos de configuración públicos en GitHub aparecieron secretos que guardó el propio Claude Code.

Cómo llega un secreto a la configuración

Claude Code tiene un sistema de permisos. Cuando aceptas «no volver a preguntar» sobre un comando concreto, el agente añade una regla a un archivo de configuración dentro de la carpeta .claude. Hay un settings.json compartido, que normalmente se sube al repositorio junto con el proyecto, y un settings.local.json local para reglas personales.

El problema es que la regla describe el comando literalmente, con todos sus argumentos. Supongamos que pediste al agente hacer una petición con curl y pegaste el token directamente en la cabecera. El agente recordará esa cadena completa y el token acabará en el archivo en texto plano. Esto es una ilustración del mecanismo, no una cita del informe. Pero la lógica es exactamente esa: no «guardaste» nada, pulsaste un botón de comodidad.

Después actúa la inercia humana de siempre. Alguien sube la carpeta .claude entera porque contiene «ajustes útiles para el equipo». El repositorio resulta ser público y el secreto queda a la vista.

Por qué no es una minucia

Estamos acostumbrados a que los secretos se filtren desde .env, desde configuraciones de la nube o desde cadenas incrustadas en el código. Los archivos de configuración de los agentes no encajaban en ese cuadro: se percibían como «preferencias personales del editor», como el tema de colores. Pero ahí ya hay permisos ejecutables: qué puede ejecutar el agente sin preguntar. Por tanto, el archivo tiene dos funciones a la vez: política de seguridad y posible almacén de secretos.

Hay algo aún más importante. Estos archivos no los escribe una persona, sino una herramienta, y en respuesta a un clic, no a la decisión consciente de «guardar la configuración». Nadie relee lo que no escribió. De ahí la conclusión de Qodo: la configuración de los agentes debe revisarse como código.

Qué hacer ahora mismo

• Revisa tus repositorios. Busca en .claude/ cadenas que parezcan claves, tokens y contraseñas, también en el historial de git. No basta con eliminar el archivo en el último commit: el historial permanece.
• Rota todo lo que encuentres. Si un token estuvo alguna vez en un repositorio público, considéralo comprometido.
• Protege el archivo local. settings.local.json debe estar en .gitignore. No des por hecho que alguien ya lo hizo.
• Saca los secretos de los propios comandos. Pásalos mediante variables de entorno o un gestor de secretos; así en la regla quedará el nombre de la variable, no el valor.
• Activa la automatización. Un escáner de secretos en pre-commit y CI y, en GitHub, también push protection. Añade .claude a CODEOWNERS para que los cambios en los permisos del agente no eludan la revisión.
• No abuses de «Don't ask again». Para comandos con argumentos sensibles es mejor confirmar cada vez o escribir a mano una regla estrecha.

Limitaciones y salvedades

El informe lo publicó Qodo, un proveedor de herramientas de revisión de código. El tema le es afín y lo presenta en consecuencia. Además, del anuncio no se desprende cuántos de los secretos encontrados estaban activos. Y 1122 archivos es lo que apareció en la búsqueda pública, no el panorama completo: nadie contó los repositorios privados.

Aun así, la crítica no es solo contra un producto. El mismo mecanismo de «recordar el comando» existe en otras herramientas de agentes, y se les aplican las mismas preguntas. Una expectativa razonable hacia los desarrolladores de agentes: enmascarar o no guardar los valores que parezcan secretos y avisar antes de escribir.

Conclusión

Las herramientas agénticas crean una nueva clase de artefactos: configuraciones que se escriben solas, se ejecutan con tus permisos y acaban fácilmente en git. Trátalas como código: revisión, escaneo, .gitignore. Es más barato que lidiar con las consecuencias de una clave filtrada.