Ejecuta esta lista de verificación de recepción de Git antes de que tu agente de código toque un repositorio no confiable
Trata los repositorios entrantes como una recepción hostil: deshabilita las rutas ejecutables de la configuración de Git y fija las versiones parchadas del agente antes de que se ejecute cualquier comando de actualización del índice.
El vector GitSpawn requiere que el repositorio llegue como archivos con .git intacto, como un archivo compartido, una unidad, una carpeta de sincronización o una memoria USB, en lugar de un clon ordinario. Un agente de código ejecuta luego git status o git diff, y Git ejecuta un helper denominado en la configuración core.fsmonitor del .git/config del repositorio. El trabajo del operador es detener esa ejecución antes de que el agente toque el repositorio.
La configuración de Git es el vector de recepción
Manifold Security encontró ocho vulnerabilidades de GitSpawn en siete agentes de código CLI; cuatro no estaban parchadas en el momento de la publicación. La exposición es lo suficientemente amplia como para requerir una puerta de control automatizada, no un simple aviso. Los operadores deben separar la recepción del repositorio de la ejecución del agente antes de que se ejecute cualquier comando de actualización del índice. Ejecútala antes del primer comando del agente, no después de un fallo.
La recepción necesita una puerta de control
El repositorio entra en un área de preparación antes de que el agente lo vea. El paso de preparación verifica la configuración del repositorio, la versión del agente y el origen de los archivos. Si alguna verificación falla, el repositorio se mantiene fuera del espacio de trabajo del agente. La puerta de control ejecuta las mismas verificaciones para cada repositorio, ya sea que el origen sea un compañero de equipo, un proveedor o un archivo público. La puerta de control debe ser la misma para cada operador, cada máquina y cada ejecutor de CI.
El área de preparación debe permanecer fuera del espacio de trabajo del agente hasta que las verificaciones pasen. El operador o el trabajo de CI es responsable de la decisión de mover el repositorio al espacio de trabajo del agente. Esa decisión debe constar en el registro de recepción.
En las máquinas de desarrollo, la puerta de control es local. El operador deshabilita la ruta ejecutable de configuración, inspecciona los metadatos del repositorio y confirma la compilación del agente antes de ejecutarlo. En CI, la puerta de control es un trabajo. El trabajo recibe los archivos, ejecuta las verificaciones y solo entonces inicia el agente. El agente no debe tener una ruta permanente al archivo sin procesar.
Las rutas ejecutables de configuración en los metadatos activan la cuarentena y un registro de origen. Las compilaciones de agente por debajo de la versión parchada detienen la ejecución y requieren una actualización. La recepción basada en archivos permanece no confiable hasta que las verificaciones pasen.
Mantén un registro de recepción breve. Registra el nombre del repositorio, el tipo de origen, la versión del agente y el resultado de la verificación de metadatos. El registro demuestra que la puerta de control se ejecutó y ofrece una forma rápida de encontrar el repositorio que causó un incidente posterior. Si el registro no existe, trata la ejecución como no verificada. El registro debe ser lo suficientemente completo como para auditarlo.
La lista de verificación es el control
Ejecuta estas verificaciones antes de que el agente ejecute cualquier comando de actualización del índice. Cada elemento es verificable en un minuto.
- Establece core.fsmonitor en false en la configuración global de Git.
- Abre .git/config y busca core.fsmonitor, core.hooksPath, attr.tree y comandos de filtro clean o smudge.
- Verifica la ruta de llegada: archivos con .git intacto, no un clon ordinario.
- Fija el agente a una versión parchada y registra la versión antes de usarlo.
- No confíes solo en safe.bareRepository.
Un elemento fallido detiene la ejecución y requiere una corrección del entorno antes de que el agente abra el repositorio. El mismo orden funciona en un portátil y en CI: deshabilita el helper, inspecciona la configuración, verifica la ruta de llegada, fija la versión y rechaza las salvaguardas parciales.
Las fijaciones de versión son la última puerta de control
El problema de core.fsmonitor de Claude Code se informó el 26 de junio y se corrigió en la versión 2.1.196 el 29 de junio. Una ruta separada de Claude Code a través de claude ultrareview permaneció activa, con el comportamiento verificado en la versión 2.1.252 el 1 de septiembre. Goose 1.41.0 contenía el punto de entrada de GitSpawn; la versión 1.44.0 incluyó la corrección. Las compilaciones de Codex CLI por debajo de 0.131.0 seguían expuestas el 2 de septiembre, cuando la versión actual era 0.152.1.
Una compilación por debajo de la versión parchada impide que el agente abra el repositorio. Un agente que no puede actualizarse se ejecuta en un entorno desechable, con el repositorio mantenido fuera del espacio de trabajo normal.