Google'ın Gemini CLI'ı artık build dosyalarını düzenlemeden önce izin istiyor

Çarşamba günü yayınlanan Gemini CLI 0.61.0, ajanın build yapılandırma dosyalarını düzenlemesinden, ardından build ya da test komutu çalıştırmasından ve argümanları güvenilmeyen dış içerikten gelen shell komutlarını yürütmesinden önce açık onay istiyor. Aynı sürüm isteğe bağlı sandbox'ı da sıkılaştırıyor: ana makinenin kimlik bilgileri sandbox içindeki süreçlerin erişemeyeceği yerde kalıyor.

Build dosyaları saldırı vektörüne dönüşüyor

package.json, Makefile, pyproject.toml veya Bazel BUILD dosyasındaki tek bir değişiklik yeni bir bağımlılık çekebilir ya da bir betiği tetikleyebilir; Gemini CLI bu düzenlemeleri web aramalarından gelen bilgilerle yapıp ardından shell komutları çalıştırabiliyor. Bir hatayı düzeltirken okunan dokümantasyon postinstall betiği eklemek için gizli talimat içeriyorsa, ajan geliştirici hiçbir komut yazmadan zararlı kodu yürütebilir.

Pull request #29250 bu senaryoyu hedefliyor. Tanınan build dosyalarındaki düzenlemeler artık onay gerektiriyor ve CLI bir oturumda hangi build dosyalarının değiştiğini izliyor; böylece sonraki npm run, make veya cargo komutları açık onay alınmadan bekletiliyor. Onay penceresi tam diff'leri gösteriyor, kısaltmıyor.

Güvenilmeyen argümanlar onay bekliyor

İkinci kontrol komut argümanlarını kapsıyor: web'den çekilen içerik, MCP sunucu yanıtları, Google Docs ve Google'ın iç hata takipçisi Buganizer artık güvenilmeyen bağlam sayılıyor ve CLI, bu içerikteki token'larla eşleşen bayrak ya da argüman taşıyan shell komutundan önce onay istiyor. Pencerede kalıcı onay yok; bu işlemler için "her zaman izin ver" verilemiyor.

Kontroller, kullanıcının güvenilir olarak işaretlemediği klasörlere uygulanan restricted workspace mode'a bağlı; PR, güvenilir klasörde ya da otomatik onayda davranışı belirtmiyor. Token eşleştirme her değerin kaynağını izlemiyor; tırnaklı argümanlar, ortam değişkeni önekleri, shell yönlendirmesi ve Windows yolları gibi atlatma yolları 11 Eylül'de birleştirme öncesinde düzeltildi.

Sandbox kimlik bilgilerini dışarıda tutuyor

İkinci pull request, #29214, sandbox'ı sıkılaştırıyor. Sandbox Docker, Podman, LXC veya macOS Seatbelt üzerinden çalıştığında ana makinenin ~/.gemini dizini artık içeriye bağlanmıyor; CLI bunun yerine kullanıcı ayarlarının API anahtarları, hooks ve özel komutları ayıklanmış temiz kopyasını aktarıyor. Sandbox ev dizini gibi hassas konumlarda başlatılamıyor; yeni Seatbelt kuralları OAuth kimlik bilgilerine ve .env dosyalarına erişimi engelliyor.

Google'ın dokümantasyonu sandbox'ı AI işlemleriyle ana sistem arasında bir güvenlik bariyeri olarak tanımlıyor, ancak riski azalttığını, ortadan kaldırmadığını ekliyor. Boşluk somut: sandbox proje dizinini bağlıyor, dolayısıyla içinde yazılan zehirlenmiş bir package.json, bir CI işi build'i dışarıda çalıştırdığında depoda duruyor.

18 Haziran'dan beri açık kaynaklı araç çoğunlukla kurumsal müşterilere ve ücretli API anahtarı olan geliştiricilere hizmet ediyor; Google Mayıs'ta Pro, Ultra ve ücretsiz kullanıcıların kapalı kaynak Antigravity CLI'ya geçeceğini duyurmuştu. Güvenlik çalışmaları açık yürütülüyor.