Gemini CLI тепер запитує дозвіл перед редагуванням файлів збірки

Gemini CLI 0.61.0, випущений у середу, тепер вимагає явного підтвердження, перш ніж агент відредагує файли конфігурації збірки, запустить build- або тестові команди після такої правки, чи виконає shell-команду, аргументи якої схожі на дані з ненадійного джерела. Той самий реліз зміцнює необов'язковий sandbox: облікові дані й конфігурація хоста стають недоступними для процесів усередині.

Файли збірки як вектор атаки

Одна зміна в package.json, Makefile, pyproject.toml або BUILD-файлі Bazel може підтягнути залежність чи запустити скрипт, а Gemini CLI здатен робити такі правки на основі вебпошуку й зовнішніх інструментів, а потім виконує shell-команди. Якщо в документації, прочитаній під час виправлення бага, є прихована інструкція додати postinstall-скрипт, агент може запустити тести й виконати шкідливий код без жодної команди від розробника.

Pull request #29250 спрямований саме на цей сценарій. Правки у визнаних файлах збірки тепер потребують підтвердження, а CLI відстежує, які файли збірки змінилися за сесію, тож подальші npm run, make чи cargo утримуються до явного схвалення. Діалог показує повні діфи файлів збірки, а не скорочені.

Ненадійні аргументи потребують схвалення

Друга перевірка стосується аргументів команд: вміст із вебзавантажень, відповідей MCP-серверів, Google Docs і Buganizer (внутрішнього трекера Google) тепер вважається ненадійним контекстом, і CLI питає дозвіл перед shell-командою, чиї прапорці або аргументи збігаються з токенами звідти. У діалозі немає опцій постійного схвалення — «always allow» для цих дій видати не можна.

Перевірки прив'язані до restricted workspace mode, безпечного режиму для тек, які користувач не позначив як довірені; у PR не сказано, як вони поводяться в довіреній теці чи за автопідтвердження. Зіставлення токенів не відстежує походження кожного значення: рев'ю виявило раніші обхідні шляхи — аргументи в лапках, префікси змінних середовища, цілі shell-перенаправлення, обробку шляхів Windows — і всі їх виправили до 11 вересня.

Sandbox не пускає до облікових даних

Другий pull request, #29214, зміцнює sandbox. Коли він працює через Docker, Podman, LXC або macOS Seatbelt, каталог ~/.gemini хоста більше не монтується всередину; замість нього CLI передає очищену копію налаштувань без API-ключів, hooks і власних команд інструментів. Sandbox не можна запустити в чутливих місцях, як-от домашній каталог, а нові правила Seatbelt забороняють доступ до OAuth-даних та файлів .env.

Документація Google називає sandbox захисним бар'єром між AI-операціями та хост-системою, застерігаючи, що він зменшує ризик, але не усуває його. Прогалина очевидна: sandbox монтує каталог проєкту, тож «отруєний» package.json, записаний усередині, залишається в репозиторії, коли CI запускає збірку зовні.

Від 18 червня відкритий інструмент переважно обслуговує корпоративних клієнтів і розробників із платними API-ключами — після того, як у травні Google оголосила, що користувачі Pro, Ultra та безкоштовного тарифу переходять на закритий Antigravity CLI. Робота над безпекою все ще ведеться публічно.