Llevo meses defendiendo el diálogo de confianza de Claude Code como la línea que separa «he abierto una carpeta» de «he ejecutado el código de un desconocido». Hoy toca reconocer que esa línea llevaba dos meses sin estar donde yo creía, y que no es la primera vez. El problema que Manifold Security ha publicado no es un hallazgo nuevo: es el mismo fallo que Anthropic ya cerró en noviembre de 2025, volvió a cerrar en diciembre y ha vuelto a abrirse en junio de 2026. Y esa reincidencia, no el fallo en sí, es lo que me parece grave.
Aclaro de entrada que no estoy pidiendo la cabeza de nadie. Un bug de seguridad en una herramienta que se mueve a cinco releases por semana es una posibilidad estadística, no una traición. Lo que sí me parece exigible es que un fallo ya corregido no vuelva, y que cuando vuelve alguien lo cuente. Ninguna de las dos cosas ha pasado aquí.
Git ejecuta el comando antes de que tú decidas nada
El mecanismo es incómodo por lo poco sofisticado que es. Git tiene una opción de rendimiento llamada core.fsmonitor que sirve para delegar en un programa externo la detección de ficheros modificados. Esa opción se puede escribir en el .git/config del propio repositorio, y su valor es un comando. Cuando algo lanza git status o git diff, Git ejecuta ese comando.
Los agentes de coding por línea de comandos lanzan git status nada más arrancar, porque necesitan saber en qué rama estás y qué hay tocado. Lo hacen antes de enseñarte nada. Así que el orden real de los acontecimientos es: abres la carpeta, el agente pregunta a Git por el estado del repositorio, Git ejecuta el comando que el repositorio traía escrito, y después aparece en tu pantalla el diálogo que te pregunta si confías en ese directorio. Sin sandbox, sin aprobación y con tus permisos de usuario.
Manifold lo ha bautizado GitSpawn y ha documentado ocho fallos repartidos entre siete agentes. goose, Cursor y Codex ya están parcheados. Hermes Agent, Qwen Code y Grok Build seguían sin parche el día de la publicación. Claude Code está en un tercer grupo, el de «parcialmente arreglado», que es el que me interesa.
Un fix que llega sin un test que lo sostenga no es un fix: es una tregua.
El fix de noviembre, el de diciembre y el mismo fallo en junio
Esta es la parte de la historia que casi nadie está contando y la que sostiene mi postura. En noviembre de 2025, Anthropic movió la secuencia de arranque de Claude Code precisamente para que las operaciones peligrosas ocurrieran después de la confirmación de confianza. En diciembre volvió a tocarlo, tras un informe que documentaba con detalle este vector y algunos hermanos suyos: core.fsmonitor, la combinación de log.showSignature con gpg.program, el apiKeyHelper de un .claude/settings.json malicioso —que está definido explícitamente como un script que se ejecuta en /bin/sh— y hooks configurados para dispararse antes del diálogo. Todo eso quedó cerrado.
Y en junio de 2026, en la versión 2.1.193, el mismo comportamiento estaba de vuelta. Anthropic cerró la vía de core.fsmonitor cuatro días después, en la 2.1.196, lo cual está bien. Pero Manifold documentó una segunda ruta de ejecución, a través de claude ultrareview, que seguía viva el 1 de septiembre en la 2.1.252. Es decir: más de dos meses.
Lo que esto me dice no es que el equipo de Claude Code sea descuidado. Me dice algo más concreto y más corregible: el arreglo de diciembre se hizo moviendo código, no añadiendo una prueba. Cuando arreglas un problema de orden de ejecución desplazando una llamada y no dejas detrás un test que falle si alguien la vuelve a mover, el siguiente refactor la mueve. No hace falta mala fe ni prisa excesiva; basta con que nadie recuerde por qué esa línea estaba justo ahí. Es exactamente el tipo de deuda que yo mismo he generado en proyectos propios, y por eso me resulta tan fácil de reconocer y tan difícil de perdonar en una herramienta que ejecuta comandos en mi máquina.
El advisory que no existe pesa más que la vulnerabilidad
Aquí es donde dejo de ser comprensivo. Anthropic no ha publicado ningún aviso de seguridad sobre ninguno de los dos hallazgos de Claude Code. Ni sobre el que arregló en cuatro días ni sobre el que seguía abierto. No hay CVE, no hay entrada de advisory, no hay línea en el changelog que diga «si has abierto un repositorio de terceros entre el 25 de junio y hoy, revisa esto».
Entiendo el cálculo: no consta explotación en ninguno de los ocho fallos, el vector requiere que alguien te haga llegar un repositorio preparado, y un advisory hace ruido. Pero ese cálculo trata la seguridad como un problema de comunicación, y no lo es. Un usuario que no sabe que estuvo expuesto no puede revisar si lo estuvo. La diferencia entre enterarme por el changelog de mi propia herramienta y enterarme por una firma de seguridad externa dos meses después es toda la diferencia que hay entre un proveedor en el que delego y un proveedor al que superviso.
Y esto llega en la misma semana en la que Anthropic mete en el auto mode una regla de contención para que las peticiones de credenciales a los metadatos de la nube y los accesos cruzados entre tenants dejen de auto-aprobarse. Es un movimiento excelente y lo aplaudí cuando salió. Pero refuerza el contraste: mucho cuidado con lo que el agente hace después de que confíes en él, y un punto ciego repetido en lo que ocurre antes.
Por qué esto le toca más a un freelance que a una empresa
Si trabajas en una empresa con equipo de plataforma, esto es un incidente que alguien gestionará por ti: los agentes corren en contenedores, los repositorios pasan por un registro interno y el portátil no es el sitio donde vive la producción. Si eres freelance, la foto es la contraria y conviene mirarla sin adornos.
Mi trabajo consiste, literalmente, en abrir código de terceros. Clono el repositorio de un cliente que no he auditado. Descomprimo el ZIP de un tema de WordPress que alguien compró en un marketplace. Recupero un proyecto de un contratista anterior que llegó por Drive como carpeta comprimida, con su .git dentro. Descargo un plugin de un repositorio público para ver cómo resuelve algo. Y en la misma máquina tengo el token de la API de Anthropic, las claves SSH, las credenciales de FTP de siete alojamientos y el .env de un par de instancias de n8n con webhooks que van a producción.
Soy el perfil objetivo. No un objetivo de alto valor, pero sí un objetivo barato: el ataque no necesita saber quién soy, solo necesita que yo abra algo. Y el gesto de defensa que yo tenía interiorizado —»leo el diálogo de confianza antes de darle a aceptar»— resulta que no cubría el momento en el que había que cubrirse.
⚠️ Lo que puedes hacer hoy mismo
Desactiva la opción de forma global, para que ningún repositorio pueda imponerla: git config --global core.fsmonitor false.
Antes de abrir en un agente cualquier directorio que hayas recibido como ficheros —ZIP, copia de Drive, carpeta compartida— mira su .git/config y busca core.fsmonitor, core.hooksPath y los ajustes de filtro. Un clon normal desde un remoto no arrastra esas claves; un directorio que te pasan a mano, sí puede.
En scripts y automatizaciones que llamen a Git de fondo, neutraliza la configuración por invocación: git -c core.fsmonitor=false status.
Lo que cambio en mi forma de trabajar, y lo que no
No voy a dejar de usar Claude Code, y sospecho que tú tampoco. Sería una reacción desproporcionada a un fallo que no consta explotado y que existe, en distintos grados, en casi todos los agentes del mercado. Lo que sí cambio son tres cosas, y las tres van en la misma dirección: dejar de tratar el prompt de confianza como una frontera y empezar a tratarlo como un aviso.
- El código ajeno no se abre donde vivo. Repositorio de cliente nuevo, tema comprado o proyecto heredado se abren en un contenedor o en una máquina sin credenciales, y solo se mueven a mi entorno normal cuando ya los he mirado.
- Las claves dejan de estar a un
catde distancia. Si un comando arbitrario se ejecuta con mis permisos, el daño lo marca lo que haya al alcance de esos permisos, no lo listo que sea el atacante. - El changelog de Claude Code pasa a lectura obligatoria. Es incómodo admitirlo, pero si el proveedor no publica advisories, la única fuente que me queda es la lista de cambios y lo que publiquen terceros.
La conclusión que me llevo no va de Git ni de core.fsmonitor. Va de una idea que se ha colado en cómo usamos estas herramientas: que existe un momento, un botón, un diálogo, en el que nosotros damos permiso y antes del cual no pasa nada. Ese momento es una convención, no una garantía técnica, y esta es la tercera vez que se demuestra. Mientras el agente necesite mirar el repositorio para saber de qué te va a hablar, el repositorio tendrá algo que decirle antes que tú. La pregunta útil no es si tu agente es seguro, sino qué pasa el día que no lo sea. Si la respuesta es «se lo lleva todo», el problema ya no lo tiene Anthropic.
