Gemini CLI 0.61.0 pide confirmación antes de tocar tus ficheros de build
La versión 0.61.0 del agente de codificación de Google exige aprobación humana para editar ficheros de build, lanzar builds tras esa edición y ejecutar comandos con argumentos de origen no fiable.
Gemini CLI 0.61.0 mete frenos donde antes no había ninguno. La versión, publicada esta semana, obliga al agente a pedir confirmación explícita antes de editar ficheros de configuración de build, antes de lanzar comandos de build o de test después de haberlos tocado, y antes de ejecutar comandos de shell cuyos argumentos parezcan venir de contenido externo no fiable. En el mismo lanzamiento, Google blinda el sandbox opcional para que las credenciales y la configuración del host queden fuera de su alcance.
El contexto importa: en el I/O de mayo Google anunció que movería a los usuarios de Pro, Ultra y del plan gratuito a Antigravity CLI, de código cerrado. Desde el 18 de junio, Gemini CLI sirve sobre todo a clientes enterprise y a desarrolladores con clave de API de pago, y Google prometió que seguiría recibiendo actualizaciones de modelo, correcciones y parches de seguridad. Esos parches se siguen desarrollando en público.
Ficheros de build como vector
El pull request #29250 apunta a esa secuencia. Un cambio en package.json, Makefile, pyproject.toml o un BUILD de Bazel puede arrastrar una dependencia o disparar un script. Si la documentación que el agente consulta mientras arregla un bug trae instrucciones ocultas para añadir un postinstall a package.json, el agente puede hacer la edición, lanzar la suite de tests y ejecutar el código malicioso sin que el desarrollador teclee un solo comando. Ahora esas ediciones exigen confirmación y el CLI lleva la cuenta de qué ficheros de build cambian durante la sesión, de modo que retiene cualquier npm run, make o cargo posterior hasta que haya aprobación. El diálogo muestra el diff completo, sin truncar.
El segundo control cubre los argumentos. El CLI trata como contexto no fiable lo que llega de fetches web, respuestas de servidores MCP, Google Docs y Buganizer, el gestor de incidencias interno de Google, y pregunta antes de ejecutar un comando cuyas flags o argumentos coincidan con tokens de ese contenido. En ninguno de los dos casos aparece el «permitir siempre»: no hay aprobación permanente para estas acciones.
Ambos cambios van ligados al modo de espacio de trabajo restringido, y el PR no detalla qué ocurre en una carpeta marcada como fiable ni bajo autoaprobación. La comprobación de argumentos compara tokens, no traza la procedencia de cada valor. El revisor automático de Google cazó en versiones previas formas de sortearla —argumentos entrecomillados, prefijos de variables de entorno, destinos de redirección del shell, rutas de Windows—, todas corregidas antes de fusionar el cambio el 11 de septiembre.
El sandbox deja de ver el home
El pull request #29214 aprieta el sandbox. Cuando corre sobre Docker, Podman, LXC o Seatbelt de macOS, el ~/.gemini del host ya no se monta dentro: se pasa una copia saneada de los ajustes, sin claves de API, hooks ni comandos de herramientas propias. También se impide arrancar el sandbox en ubicaciones sensibles como el directorio home, y las nuevas reglas de Seatbelt bloquean el acceso a credenciales OAuth, decisiones de carpetas de confianza y ficheros .env. La documentación de Google describe la función como una barrera de seguridad entre las operaciones de la IA y el sistema anfitrión, con el aviso de que reduce el riesgo sin eliminarlo.
Las dos capas se necesitan. El sandbox limita hasta dónde llega un proceso una vez arrancado; las confirmaciones deciden si el agente llega a ejecutar una acción sensible. El hueco se ve con los ficheros de build: el sandbox monta el directorio del proyecto para que el agente lo edite, así que un package.json envenenado escrito dentro sigue en el repositorio cuando un desarrollador o un job de CI lanza el build fuera.
Quien ya tenga un servidor MCP con la confianza marcada seguirá sin ver una sola pregunta: ese ajuste salta todas las confirmaciones de llamadas a herramientas de ese servidor, y los ataques de envenenamiento de herramientas y de rug pull han demostrado que un servidor aprobado hoy puede devolver contenido del atacante mañana. La mitigación llega a los ficheros de build y al sandbox, no a la confianza concedida en su día.
