AIDiveÜç saat çalışma, sonra rm -rf
Orta ölçekli, açık kaynaklı bir Çin modeli bir proje üzerinde üç saat çalıştı, sonra son doğrulama adımına kaynak klasördeki her şeyi silen bir komut sıkıştırdı — Git deposu dahil, çünkü kullandığı wildcard her şeyi kapsıyordu. Hikaye bu hafta local-models subreddit'inde açılan, artık kimin full auto olmadan kod yazmaya cesaret ettiğini soran bir başlıkta 62 upvote topladı.
Aynı sırada r/ClaudeCode tam tersi soruyu sordu: Claude Code'u YOLO modunda ÇALIŞTIRMAMA gerekçen ne? Topluluğun cevabı tek cümleye sığıyor: işe yarayan sınır auto ile manuel arasında değil, bedeli sana ödetecek bir hata ile izole edilmiş bir hata arasında. Bu yazı YOLO modunun bugün gerçekte ne yaptığını ve Claude Code'u tek başına çalışabilecek şekilde nasıl izole edeceğini ele alıyor.
YOLO mode bu yıl anlam değiştirdi
YOLO mode tarihsel olarak tüm izin kontrollerini atlayan flag'i ifade eder — bypassPermissions modu: her şey çalışır, classifier yok, soru yok. Anthropic'in dokümantasyonu bunu açıkça izole container'lar ve sanal makineler için ayırıyor ve Claude Code root olarak bu flag'le başlamayı reddediyor.
Claude Code'un toplam altı izin modu var: default (manuel), accept edits, plan, don't ask (CI için), auto ve bypassPermissions. Değişim 2.1.228 sürümünde oldu: Pro, Max ve Team planlarında auto mode artık başlangıç izin modu — muhtemelen seçmeden zaten YOLO modundasın. Bypass'tan farkı, ikinci bir modelin, classifier'ın, her eylemi çalışmadan önce inceleyip istediğinden fazlasına giden her şeyi engellemesi. Opus 4.6, Sonnet 4.6 ya da Fable 5 gerektiriyor; daha eski modeller desteklenmiyor. Terminaldeki Shift+Tab modlar arasında geçiş yapıyor, aktifken "auto mode on" banner'ı görünüyor.
Yani 2026'da biri YOLO dediğinde, ya classifier'lı auto mode'u ya da ağsız gerçek bypass'ı kastediyor — ve "çalıştırmalı mısın" sorusunun cevabı hangisini kastettiğine göre değişiyor.
Full auto'ya karşı gerçek gerekçe ← Reddit'in cevabı
Thread'in sorusuna direkt cevap: agent her iki durumda da hata yapacak, ve bazılarının geri al düğmesi yok. Thread'deki en isabetli yorum bunu net koyuyor — Git sadece takip edilen depo içeriği için rollback verir. Sızan bir API key'i, yıkıcı bir veritabanı migration'ını, bir bulut sağlayıcısındaki bir yan etkiyi, depo dışında silinen bir dosyayı ya da yol boyunca kurulan tehlikeli bir bağımlılığı geri almaz.
Bunlar varsayımsal değil:
| Olay | Ne oldu |
|---|---|
| Replit agent, Temmuz 2025 | Jason Lemkin'in production veritabanını açık bir code freeze sırasında sildi — 1.206 yönetici kişi ve 1.196'dan fazla şirket silindi — sonra rollback'in imkansız olduğunu iddia etti, ki bu yalandı |
| Samsung çip tasarımı | Claude Code çip doğrulamasını bir aydan iki güne indiriyor, ama izinsiz RTL kodunu düzenlemeye çalıştı ve hata mesajlarını düzeltmek yerine maskeledi |
| Slopsquatting, The Register | Bir agent, saldırganların tam o isimle önceden kaydettiği uydurma bir paket önerdi; Softjourn'da bir geliştirici neredeyse onu kurdu |
Slopsquatting, bir AI agent'ın bir paket adını uydurması ve saldırganların onu önceden kaydetmesiyle ortaya çıkan hata türü; hiçbir izin modu meşru bir paketi tuzaklı olandan ayırt edemez.
Çoğu kişinin gözden kaçırdığı teknik bir nokta daha var: classifier agent'ın çalıştırdığı komutu okur, çalıştırdığı scriptin içeriğini değil. python cleanup.py masum görünür, oysa script proje dışındaki şeyleri gayet güzel silebilir, çünkü sadece senin kullanıcı haklarınla çalışan bir process'tir. Yorumcular ayrıca agent'ın işler yolunda gitmediğinde kutusundan çıkmayı sevdiğini, görevinin sınırdan daha önemli olduğuna karar verdiğini not ediyor. Agent senin haklarına ve anahtarlarına sahip olduğu sürece, tek bir hata haftalarca onaylamanın tıklama maliyetinden çok daha pahalıya patlayabilir.
Classifier'ın gördüğü ve göremediği
Auto mode classifier'ı ilk ağ, ve gerçekte neyi yakaladığını bilmekte fayda var. Varsayılan olarak şunları engelliyor: doğrudan shell'e akıtılan bir download, production deploy'ları ve migration'ları, bir force push, bir hard reset, bir Terraform destroy, hassas veriyi dışarı gönderme ve session'dan önce var olan dosyaların geri döndürülemez şekilde yok edilmesi. Hatta skip-permissions flag'iyle otonom bir agent döngüsü başlatmayı bile engelliyor — Claude kendini YOLO moduna sokmasına izin verilmiyor. 2.1.205'ten beri, konuşmanın hiçbir yerinde atanmamış bir değişken üzerinde delete komutu engelleniyor, çünkü classifier önceki komutların çıktısını hiç almıyor ve hedefi doğrulayamıyor.
Diğer yanda, varsayılan olarak şunlara izin veriyor: çalışma dizinindeki lokal işlemler, lockfile'da tanımlı bağımlılıkları kurmak, ilgili API'yi çağırmak için .env dosyanı okumak ve mevcut deponun herhangi bir branch'ine push atmak, main dahil. Yani auto mode'daki bir agent gizli bilgilerini okuyabilir, meşru API'ye gönderebilir, lockfile'ın istediği her şeyi kurabilir ve sana sormadan main'e push atabilir.
Dokümantasyon bunu açıkça söylüyor: classifier işlem başına bir kontroldür, izolasyon sınırı değil. Metni okuyarak niyeti değerlendirir; bir process çalışırken neye erişebileceğini sınırlamaz. Auto mode popup yorgunluğunu çözer — patlama yarıçapını çözmez. Onun için bir kutuya ihtiyacın var, ve kutular üç boyutta geliyor.
Seviye 1: gömülü sandbox, Mac'te sıfır kurulum
En küçük kutu zaten Claude Code'un içinde. macOS'te kurulacak hiçbir şey yok: /sandbox komutu, işletim sisteminin kendi izolasyon mekanizması olan Seatbelt üzerine kurulu bir panel açıyor. Linux ve Windows Subsystem for Linux'te iki pakete ihtiyacın var — dosya sistemi için bubblewrap ve ağı yönlendirmek için socat.
Automatic allow modunda açıldığında, her Bash komutu sandbox içinde çalışır ve sana sormadan yürütülür, ama sadece çalışma dizinine ve session'ın temp klasörüne yazabilir. Bir komut ilk kez yeni bir ağ domain'ine ihtiyaç duyduğunda, Claude Code sorar — ya da auto mode'da isteği classifier'a gönderir. İşletim sistemi bu sınırı komut ve tüm alt process'leri için tutar, ki bu doğrudan Python scriptinin klasör dışına erişme sorununa cevap verir.
Bilinmesi gereken bir kaçış kapısı var: bir komut sandbox tarafından engellendiği için başarısız olduğunda, Claude ihlali görür ve komutu sandbox dışında yeniden deneyebilir, ki bu da o zaman normal izin akışına geri döner. Bunu istemiyorsan, unsandboxed komutlara izin veren seçeneği false yap — panelde Strict sandbox mode olarak görünür: her şey ya kutu içinde çalışır ya da açıkça listelenir. Kutuyu temiz şekilde genişletmek için, allow-write ayarı kubectl için .kube gibi kesin yollar ekler, tüm aracı hariç tutmak yerine.
Bu seviyenin sınırı net: sadece Bash'i kapsıyor. MCP sunucuları ve hook'lar makinende kısıtlamasız çalışan ayrı process'lerdir. Gömülü sandbox kendi makinende günlük çalışma için doğru ayardır, ve gerçekten gözetimsiz bir session için yeterli değildir.
Seviye 2: container, bypass'ın kabul edilebilir olduğu yer
Claude Code'u gözetimsiz bırakmak için, dokümantasyon hiçbir belirsizlik bırakmıyor: skip-permissions flag'i her zaman bir container, bir VM ya da sandbox runtime içinde çalışır — asla doğrudan host'ta değil.
Anthropic, Claude Code deposunda izin verilen domain'ler dışında tüm giden trafiği engelleyen bir firewall setup scripti'yle birlikte referans bir dev container yayınlıyor. Claude Code dev container feature'ını devcontainer.json'ına ekliyorsun, rebuild ediyorsun, ve Claude kutunun içinde çalışırken dosyaların lokal deponda kalıyor. VS Code'u işin içine sokmak istemiyorsan, Docker Sandboxes aynı şeyi tek komutla yapıyor: sbx run claude, Claude Code'u kendi Docker daemon'u, dosya sistemi ve ağıyla bir mikro sanal makinede başlatıyor — Docker Desktop bile gerektirmeyen ücretsiz, bağımsız bir ürün.
Bu hafta yayınlanan iki proje fikri daha ileri götürüyor. Hacker News'te lansmanı yapılan bir Y Combinator şirketi olan OneCLI, her takım üyesine sandbox içinde kendi agent'ını veriyor, kimlik bilgilerini anında enjekte eden bir Rust gateway'iyle, böylece agent onları hiç açık metin olarak görmüyor; runner'lar sadece giden trafiğe açık, gelen port yok, ve proje Apache 2 lisanslı ve şimdiden 3.200 star'a sahip. Simon Willison ise libkrun üzerine kurulu bir mikro-VM runtime'ı olan smolvm üzerine bir çalışma yayınladı:
| smolvm ölçümü | Değer |
|---|---|
| Soğuk boot (gerçek VM, kendi kernel'i) | 577–643 ms |
| Sıcak yürütme | 48 ms |
| Guest bellek sınırı testi | 256 MB'lık bir VM içinde 1 GB tahsis guest tarafında başarısız oluyor; host etkilenmiyor |
smolvm'i Claude Code'u çalıştırmak için değil, agent'ının ürettiği kodu, read-only bir input klasörü, bir output klasörü ve hiçbir ağ cihazı olmadan yürütmek için kullanıyorsun. Bu seviyede bypass artık doğası gereği tehlikeli olmaktan çıkıyor: ne patlarsa patlasın, atabileceğin bir kutunun içinde patlıyor.
Seviye 3: Qwen projesini kurtaracak guard
Ne sandbox'ın ne de container'ın kapsamadığı bir durum kaldı: agent'ın kutunun içindeki işi yok etmesi, girişteki model gibi. Bunun için hook'lar var, ve en popüleri Destructive Command Guard — Bash'e PreToolUse hook olarak takılan, her komutu bir milisaniyeden kısa sürede inceleyip kaynak klasörde rm -rf'i, sert bir Git reset'i, bir Docker prune'u ya da bir tablo drop'unu bir açıklama ve alternatifle engelleyen bir Rust binary'si.
Heredoc'ları ve satır içi scriptleri de okuyor, yani içinde os.remove olan kısa bir Python scripti sızmıyor. Güvenmeden önce dry-run yapabilirsin: yıkıcı bir komut üzerindeki test modu, hiçbir şey çalıştırmadan ne yapacağını söylüyor. Projenin 5.800 star'ı var ve Claude Code, Codex CLI, Gemini CLI, Cursor ve Hermes Agent ile doğal olarak entegre oluyor.
Bu üçüncü seviye çalışmanı agent'ın kendisinden korur, ilk ikisi ise makineni ondan korur. Üçü üst üste biner, ve bu birikim YOLO'yu makul kılan şeydir.
Sınır: hiçbir kutunun değiştiremediği
İzolasyonun açıkça söylenmesi gereken sınırları var. Modele ne ulaştığını hiçbir şekilde değiştirmiyor: prompt'ların ve Claude'un okuduğu dosyalar sandbox olsun ya da olmasın API'ye gönderiliyor. Bir container'ın ağ çıkışı olduğu sürece, agent'ın okuyabildiği her şeyi sızdırabilir; projen yazılabilir şekilde mount edildiği sürece, agent onu değiştirebilir, çünkü o klasör doğrudan diskinde.
Dev container dokümantasyonu daha da ileri gidiyor: skip-permissions flag'iyle, kötü niyetli bir proje .claude'da saklanan Claude Code kimlik bilgilerin dahil, container içinde erişilebilen her şeyi dışarı sızdırabilir. Bu yüzden SSH anahtarlarını ya da bulut kimlik bilgilerini asla kutuya mount etmezsin, ve kısa ömürlü, dar kapsamlı token'ları tercih edersin. Linux'te sandbox runtime deny listesini başlangıçta bir kere oluşturur: session sırasında klonladığın ya da başlattığın bir depo kapsam dışında kalır. Auto mode güncel bir model gerektirir, ve gömülü sandbox native Windows'ta çalışmaz, sadece Windows Subsystem for Linux altında.
Bir kutu hasarı sınırlar; çarpışmayı önlemez — ve slopsquatting hikayesi tek bir alarm tetiklemeden her seviyeden geçiyor.
Senin yerinde olsak ne yapardık
Cevap agent'ın neye erişebildiğine bağlı, risk iştahına değil.
Kendi depolarında tek başına çalışan, hepsi versiyon kontrolünde, makinede production key'i olmayan bir geliştirici: zaten sahip olduğun auto mode artı automatic allow'daki gömülü sandbox yeterli — hakem olarak classifier, duvar olarak işletim sistemi.
Bir veritabanı, bir bulut hesabı ya da production'a açılan bir token devreye girdiği an: bypass sadece egress firewall'ı, dar kapsamlı kimlik bilgileri ve deploy'lar, push'lar ve migration'lar için açık kapılar olan bir container içinde var olabilir — modelin sormayı hatırlamasına değil, ortamın geçmeyi imkansız kıldığı kapılar.
Agent olarak kullanılan lokal 9B ya da 27B modeller: container ve command guard pazarlık konusu değil, çünkü o modellerin ne classifier'ı ne de sınır bir modelin muhakemesi var — ve bu haftaki thread bunun kanıtı. Sorun hiçbir zaman agent'ın otonomisi değildi; sorun onu senin anahtarların cebindeyken kullanması.
