Terminalde çalışan bir AI ajanına dosya sistemine ve komut satırına erişim vermek, aslında bir yabancıya evinin anahtarını vermeye benziyor: sorun anahtarın kendisi değil, hangi kapıları açabildiğidir. Claude Code'un izin sistemi tam olarak bunu çözmek için var — hangi araçların ne zaman onay istediğini, hangi kuralların otomatik geçtiğini ve hangi komutların ajanı kendi sandbox'ından çıkardığını belirler. Bu yazıda izin katmanlarını, en sık yapılan kural-yazım hatalarını ve sandbox ile izolasyonun pratikte nasıl çalıştığını adım adım kuruyoruz.
💡 Pro Tip: Bir izin kuralını "genel olarak güvenli görünüyor" diye değil, "bu kural hangi somut komutu geçirir ve hangisini geçirmez" diye test ederek yaz — aradaki fark,rmilerm -rf /arasındaki fark kadar büyük olabilir.
İçindekiler
- Ajan izinlerini bir tehdit modeli olarak düşünmek
- İzin katmanları: her seferinde sor, oturumluk onay, kalıcı allowlist
- Kural yazımının anatomisi ve en sık üç hata
- Deny kuralları neden kaçak verir — argümana gizlenen dosya yolu ve bileşik komutlar
- Geri-döndürülemez komutlar: rm -rf, git push --force, migration apply
- İzolasyon: sandbox, konteyner ve ayrı kullanıcı ile çalıştırma
- Ekipte izin politikası: kim neyi onaylar, denetim izi nasıl tutulur
- SSS
- AI kod ajanına hangi izinleri vermek güvenli?
- Allowlist ve deny kuralları nasıl yazılır, nerede kaçak verir?
- Tüm izinleri atlamak (skip permissions) ne zaman kabul edilebilir?
- Ajanı izole çalıştırmanın en pratik yolu nedir?
- Deny kuralı yazdım, hâlâ çalışıyor — neden?
- Güncelleme (Eylül 2026)
- Sonuç
- Kaynaklar
Ajan izinlerini bir tehdit modeli olarak düşünmek
Bir terminal ajanına izin vermek tek bir açma/kapama anahtarı değil, katmanlı bir karar zinciridir. Sorman gereken soru "bu ajana ne kadar güveniyorum" değil, "bu ajan hatalı bir komut ürettiğinde ne kaybederim" sorusudur. Bu çerçevede üç şey birbirinden bağımsız çalışır: hangi araçların onay istediği (izin modu), o onayın nasıl otomatikleştirilebileceği (allowlist/deny kuralları) ve onay dışında kalan bir güvenlik katmanı olarak dosya sistemi ile ağın fiziksel olarak izole edilip edilmediği (sandbox). Üçünü birbirine karıştırmak kolaydır: bir geliştirici "allowlist yazdım, güvendeyim" diyip sandbox'ı hiç açmayabiliyor; oysa allowlist yalnız _hangi komutun sorulmadan geçeceğini_ belirler, komutun _neye erişebileceğini_ değil.
Pratikte tehdit modelini üç soruya indirebilirsin: (1) Ajan bu komutu çalıştırırsa, geri alamayacağım bir şey olur mu? (2) Bu komutun erişebileceği dosya/ağ yüzeyi, yapması gereken işin dışına taşıyor mu? (3) Bu kararı ajan yerine ben mi veriyorum, yoksa bir kural mı veriyor? Üçüncü soru özellikle kritik, çünkü izin sisteminin asıl amacı senin dikkatini "her şeye" değil, "riskli olana" yöneltmektir. Aşağıdaki bölümlerde bu üç eksenin — mod, kural, izolasyon — birbirini nasıl tamamladığını göreceksin.
İzin katmanları: her seferinde sor, oturumluk onay, kalıcı allowlist
Claude Code, güç ile güvenliği dengelemek için katmanlı bir izin sistemi kullanır. Araçlar üç kategoriye ayrılır: salt-okunur araçlar (dosya okuma, LS, Grep) hiçbir zaman onay istemez; Bash komutları ve dosya değiştiren araçlar (Edit, Write) ise onay ister — ama verdiğin "bir daha sorma" cevabının ömrü ikisinde farklıdır: Bash için bu onay proje dizini + komut bazında kalıcıdır, dosya değiştiren araçlarda ise yalnız oturum sonuna kadar geçerlidir. Bu üçlü tablo, izin sisteminin iskeletidir — geri kalan her şey (modlar, kurallar, sandbox) bu iskelet üzerine kurulur.
Modlar bu iskeleti nasıl kullanacağını belirler. default modda her yeni araç kullanımında (yeni bir Bash komutu, yeni bir dosya değişikliği) onay sorulur; acceptEdits modda dosya düzenlemeleri otomatik kabul edilir ama Bash yine sorar; plan modda ajan yalnızca okuma yapar, hiçbir değişiklik uygulanmaz; bypassPermissions modda tüm onay istemleri atlanır — bunu yalnız izole, geri dönüşü olan bir ortamda (konteyner, sandbox'lı VM) kullanmalısın.
Mod | Ne yapar | Ne zaman kullan |
|---|---|---|
default | Her yeni araç/komut kullanımında onay ister | Yeni bir projede, ajana henüz güvenmediğin ilk günler |
acceptEdits | Dosya düzenlemeleri otomatik onaylanır, Bash yine sorar | Refactor gibi çok-dosyalı ama düşük-riskli işlerde |
plan | Ajan yalnız okur/planlar, hiçbir değişiklik uygulanmaz | Mimari karar öncesi keşif, riskli görevlerin ön incelemesi |
bypassPermissions | Tüm onay istemleri atlanır | Yalnız izole bir ortamda (konteyner/VM), asla ana makinede |
Ben genelde yeni bir depoda plan modla başlayıp ajanın ne önerdiğini okuduktan sonra default'a geçmeyi tercih ederim — bu, "ajan neye dokunacak" sorusuna cevap vermeden onay düğmesine basmayı engelliyor. Kalıcı allowlist ise bambaşka bir katman: modun ne olduğuna bakmaksızın, belirli bir komut deseni için "bunu bir daha sorma" demektir. Yani mod _varsayılan davranışı_, allowlist ise _istisnaları_ tanımlar — ikisini karıştırmak, "acceptEdits açık ama her Bash hâlâ soruyor" gibi şaşırtıcı davranışlara yol açar.
Kural yazımının anatomisi ve en sık üç hata
Allowlist ve deny kuralları, Bash komutları için önek eşleştirmesiyle çalışır. Bir kural Bash(npm run test:*) şeklinde yazıldığında, npm run test ile başlayan her komutu eşler — sonek olarak :* kullanmak, "bundan sonra ne gelirse gelsin" anlamına gelir. Dosya kuralları (Read/Edit) ise farklı bir sözdizimi kullanır: gitignore spesifikasyonunu izleyen dört ayrı desen tipi vardır.
Desen tipi | Örnek | Anlamı |
|---|---|---|
Mutlak yol | //abs/yol | Diskteki tam, değişmez konum |
Ev dizini | ~/yol | Kullanıcının ev dizinine göreli |
Ayarlar-dosyasına göreli | /yol | Kuralı içeren ayar dosyasının bulunduğu dizine göreli |
Çalışma dizinine göreli | yol veya ./yol | Geçerli çalışma dizinine (cwd) göreli |
json
1{2 "permissions": {3 "allow": ["Bash(npm run test:*)", "Bash(git diff:*)", "Read(./src/**)"],4 "deny": ["Bash(curl:*)", "Edit(/docs/**)"]5 }6}Üç sık hatadan ilki tam olarak bu örnekte gizli: Edit(/docs/**) kuralı, /docs/ gibi diskin kökünü değil, kuralı içeren ayar dosyasının dizinindeki docs/ dizinini hedefler; yalnız ayar dosyası proje kökündeyse bu <proje-kökü>/docs/ demektir. Dokümantasyonun ayrıca uyardığı nokta da bu: /Users/alice/file mutlak bir yol _değildir_, mutlak yol için //Users/alice/file yazmalısın.
İkinci sık hata, MCP araçlarını kısıtlarken sunucu adı ile araç adını karıştırmaktır. MCP kuralları mcp__sunucu-adı__araç-adı biçiminde yazılır — örneğin mcp__puppeteer__puppeteer_navigate yalnız o tek aracı eşler, sunucunun tamamını değil. Bir MCP sunucusunun tüm araçlarını kapatmak istiyorsan sunucu adını tek başına yazman gerekir; aksi hâlde "izin verdim ama hâlâ soruyor" durumuyla karşılaşırsın çünkü aynı sunucunun başka bir aracı kural dışında kalmıştır.
Üçüncü hata, kuralların _ne zaman_ devreye girdiğini yanlış varsaymaktır. PreToolUse hook'ları izin sisteminden önce çalışır ve hook'un çıktısı onay/red kararını doğrudan belirleyebilir — yani bir allowlist kuralı yazsan bile, önce çalışan bir hook o kararı ezebilir. Ayarlar da tek bir dosyadan gelmez: beş seviyeli bir hiyerarşi vardır (kurumsal politikalar, komut satırı argümanları, yerel proje ayarları, paylaşılan proje ayarları, kullanıcı ayarları) ve üstteki seviye alttakini geçersiz kılar. Bir kuralın "çalışmadığını" düşündüğün anların çoğunda, aslında başka bir seviyede yazılmış çelişen bir kural devrededir.
- Önek eşleştirme:
Bash(kural:*)yalnız o önekle başlayan komutları eşler, komutun ortasındaki veya sonundaki farklı bir argümanı değil. - Ayarlar-göreli yol: Dosya kurallarında baştaki tek
/, kuralın yazıldığı ayar dosyasının bulunduğu dizine göreli anlamına gelir — diskin köküne değil. - Hiyerarşi önceliği: Kurumsal politika > komut satırı > yerel proje > paylaşılan proje > kullanıcı ayarları; üstteki her zaman kazanır.
Deny kuralları neden kaçak verir — argümana gizlenen dosya yolu ve bileşik komutlar
Bir deny kuralı yazmak, o komutun tamamen zararsız hâle geldiği anlamına gelmez — dokümantasyonun kendisi güvenlik sınırları başlığı altında aşağıdaki üç riski de tek tek sayıyor. Sandbox içinde çalışan bir ajana allowUnixSockets ile belirli soketlere erişim izni verirsen ve bu erişim yanlışlıkla /var/run/docker.sock'u kapsarsa, bu tek satır docker soketi üzerinden host sistemine etkin bir erişim açar — sandbox'ın kendisi bu riski dokümantasyonunda açıkça uyarıyordu. Aynı şekilde $PATH üzerindeki dizinlere geniş yazma izni vermek, bir ayrıcalık yükseltme (privilege escalation) yoluna dönüşebilir: ajan zararsız bir yardımcı script yazdığını sanırken, aslında PATH üzerinde çalışan bir sistem aracının yerini alabilir. enableWeakerNestedSandbox ayarı ise iç içe sandbox kullanımında izolasyonu belirgin şekilde zayıflatır ve yalnız gerçekten gerektiğinde açılmalıdır.
Bunların ortak noktası şu: deny kuralı ve sandbox izolasyonu, komutun _adını_ değil _argümanının içindeki niyeti_ değerlendiremez. Bir kural Bash(curl:*) ile curl'ü tamamen engelleyebilir ama komut adı yerine argümana gömülü bir davranış (bir soket yolu, bir $PATH yazması) kural yazan kişinin gözünden kolayca kaçabilir. Bu yüzden deny listeni yazarken kendine şunu sor: "bu kural komutun adını mı engelliyor, yoksa erişebileceği kaynağı mı?" İkincisi çok daha zor ama çok daha güvenilir bir sorudur.
Daha sinsi bir kaçak da kuralın komutun tamamını değil yalnız bir parçasını görmesidir. Dokümantasyon burada net bir güvence veriyor: Claude Code kabuk operatörlerinin (&& gibi) farkındadır, bu yüzden Bash(safe-cmd:*) gibi bir önek kuralı safe-cmd && other-cmd komutunu geçirmez. Dokümantasyonun verdiği bu güvence pratikte her kuralda tutmuyordu: bazı jokerli kuralların kabuk operatörü içeren bileşik komutlarla eşleşebildiği bir açık vardı; açık sonradan kapatıldı (bkz. Güncelleme). Jokerli kuralları dar tut, bileşik komutları elle çalıştır.
Aşağıdaki ayar parçası dar kapsamın nasıl göründüğünü gösteriyor: /var/run/*.sock gibi bir joker yerine tek bir soket yolu yazıldığında, /var/run/docker.sock kuralın kapsamına hiç girmez.
json
1{2 "sandbox": {3 "allowUnixSockets": ["/var/run/app-metrics.sock"]4 }5}Pratik kural: allowUnixSockets, $PATH yazma izni ve enableWeakerNestedSandbox gibi ayarları her zaman en dar kapsamla yaz, sonra ihtiyaç çıktıkça genişlet — tersini yapmak, yani geniş başlayıp sonradan daraltmak, aradaki pencerede fark etmeden bir kaçağı açık bırakmak demektir.
Geri-döndürülemez komutlar: rm -rf, git push --force, migration apply
rm -rf, git push --force ve bir migration'ı canlıya uygulamak, aynı kategoride üç komut değildir ama ortak bir özellikleri var: çalıştıktan sonra "geri al" seçeneğin genelde yok. Bugünkü izin sisteminde bu tür komutlar için isimlendirilmiş, ayrı bir "tehlikeli komut" sınıflandırması bulunmuyor — Bash aracı tek bir onay katmanına tabi: ya bir kural onu otomatik geçirir, ya da her seferinde sorulur. Yani rm -rf ./tmp ile rm -rf / arasında sistemin kendisi bir ayrım yapmıyor; ayrımı sen, kural yazarken yapmak zorundasın.
Bu, pratikte şu anlama geliyor: geri döndürülemez komutları allowlist'ine asla geniş bir joker ile (Bash(rm:*) gibi) koyma. Bunun yerine ya bu komutları tamamen default modun onayına bırak (yani hiç allowlist'e alma), ya da riskli komutu bütünüyle deny listesine yaz ve gerçekten gerektiğinde elle çalıştır. git push --force için de aynı mantık geçerli — bunu bir allowlist kuralına asla gömme; bu, ajanın bir branch geçmişini tek bir yanlış çıkarımla kalıcı olarak bozabileceği anlamına gelir.
Migration apply için de benzer bir disiplin öneririm: migration'ı _üretmeyi_ ajana bırak, _uygulamayı_ elle yap — üretilen dosyayı önce kendin oku, sonra kendi elinle çalıştır. Sistemin kendisi sana bu ayrımı dayatmıyor; bunu bir çalışma alışkanlığı olarak sen kurmalısın. Bugünkü hâliyle en güvenli yaklaşım şu üçlü: (1) geri döndürülemez komutları allowlist'e koyma, (2) mümkünse bu komutları plan modda önce ajanın "ne yapacağını" oku, (3) uygulama adımını sandbox dışında, kendi elinle tetikle.
İzolasyon: sandbox, konteyner ve ayrı kullanıcı ile çalıştırma
Onay kuralları bir davranış katmanıdır; sandbox ise bir fiziksel sınır katmanıdır — ikisi farklı sorulara cevap verir. Sandbox açıldığında varsayılan davranış şudur: ajan, mevcut çalışma dizinine hem okuma hem yazma erişimine sahiptir; diskin geri kalanına ise (belirli engellenen dizinler hariç) yalnız okuma erişimi vardır. Ağ tarafında da benzer bir mantık işler — ağ erişimi sandbox dışında çalışan bir proxy sunucusu üzerinden kontrol edilir ve yeni bir domain'e ilk istek, otomatik olarak bir onay istemi tetikler.
İşletim sistemi seviyesinde bu izolasyon platforma göre farklı uygulanır: Linux'ta bubblewrap ile, macOS'te ise Seatbelt çerçevesiyle. Sandbox'ı açmak tek bir komutla mümkün:
bash
1# Sandbox modunu etkinleştir2/sandboxAyrı bir kullanıcı veya konteynerle çalıştırmak, sandbox'ın üstüne eklenen ikinci bir izolasyon katmanıdır — dokümantasyon, mevcut güvenlik araçlarıyla entegrasyon başlığı altında devcontainer kullanımını doğrudan öneriyor: ajanı bir development container içinde çalıştırmak, sandbox'ın dosya-sistemi/ağ izolasyonunu, konteynerin kendi süreç ve kullanıcı izolasyonuyla katmanlar. Ben production'a yakın herhangi bir depoda ikisini birlikte kullanmayı tercih ediyorum — sandbox tek başına "bu dizinin dışına çıkma" der, konteyner ise "bu dizinin dışında zaten hiçbir şey yok" der; ikinci cümle çok daha güçlü bir garanti.
Kurum içi kullanımda bu izolasyonun somut bir faydası ölçülmüş durumda: sandboxing, izin promptu sayısını yüzde 84 azalttığı gözlemlenmiş — çünkü sandbox içinde kalan komutlar için ajan, çoğu zaman onay beklemeden ilerleyebiliyor, riskli olan yalnız sandbox dışına çıkma isteği kalıyor.
Bu izolasyon disiplini, ajanların cihaz-üstü modelleri veya yerel çıkarım araçlarını çağırdığı senaryolarda daha da kritik hâle geliyor; cihaz-üstü makine öğrenmesi modellerini çalıştıran bir ajan, hem dosya hem hesaplama kaynağına erişiyorsa sandbox'ın "yalnız cwd'ye yaz" kuralı ekstra bir güvenlik payı sağlar.
Ekipte izin politikası: kim neyi onaylar, denetim izi nasıl tutulur
Tek kullanıcılı bir projede izin kararları kişisel bir tercih; bir ekipte ise bu kararların tutarlı ve denetlenebilir olması gerekir. Bunun için iki mekanizma birlikte çalışır. Birincisi beş seviyeli ayar hiyerarşisi: kurumsal (enterprise) politikalar en üstte durur ve hiçbir geliştirici kendi yerel ayarıyla bunu ezemez; altında sırasıyla komut satırı argümanları, yerel proje ayarları (git'e girmeyen, kişisel), paylaşılan proje ayarları (git'e giren, ekip ortak) ve en altta kullanıcı ayarları gelir. Pratikte bu, "riskli komutları kim yasaklayabilir" sorusunun cevabını net bir hiyerarşiye bağlar: bir deny kuralını yalnız daha üst seviyedeki bir ayar geçersiz kılabilir; ayrıca deny kuralları, aynı seviyedeki allow ve ask kurallarının önüne geçer.
İkinci mekanizma denetim izidir: PreToolUse hook'ları izin sisteminden önce çalışıp çıktısıyla onay/red kararını belirleyebildiği için, bir ekip bu hook'u merkezi bir loglama noktası olarak kullanabilir — her Bash çağrısını, kararını ve gerekçesini kaydeden bir hook, "kim ne zaman neyi onayladı" sorusuna insan hafızasından bağımsız bir cevap verir.
json
1{2 "hooks": {3 "PreToolUse": [4 {5 "matcher": "Bash",6 "hooks": [7 { "type": "command", "command": "./scripts/log-bash-call.sh" }8 ]9 }10 ]11 }12}Ekipte pratik bir kural önerisi: paylaşılan proje ayarlarına yalnız düşük-riskli, sık tekrar eden komutları (npm run test:*, git diff:* gibi) yaz; ağ erişimi gerektiren veya dosya sistemi dışına çıkan her şeyi kurumsal politika seviyesinde merkezi olarak yönet. Bu ayrım, her geliştiricinin kendi projesinde farklı bir güvenlik yorumu geliştirmesini engeller ve gizlilik ve uyumluluk denetimini yürüten ekiplerin gereksinimlerini tek bir yerden denetlemesine izin verir.
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
Bu yazıda geçen tüm kararları tek bir kontrol listesine indirdim — yeni bir depoda ajana izin verirken sırayla gözden geçirebileceğin, hiçbir adımı atlamamanı sağlayan bir liste. Aşağıdaki maddeleri yeni bir proje kurarken veya mevcut bir allowlist'i denetlerken kullan.
SSS
AI kod ajanına hangi izinleri vermek güvenli?
Güvenli başlangıç noktası, hiçbir kalıcı allowlist kuralı yazmadan default veya plan modda çalışmaktır — bu, ajan her Bash komutunu ve dosya değişikliğini senin onayına sunar. Yalnız gerçekten sık tekrarlayan, tek başına düşük riskli komutları (test çalıştırma, git diff gibi) allowlist'e al; ağ erişimi gerektiren, dosya sistemi dışına çıkan veya geri döndürülemez olan hiçbir komutu otomatik onaya bağlama. Bunun yanına sandbox açarsan, izin kuralı olmayan komutlar bile fiziksel olarak izole bir alanda kalır.
Allowlist ve deny kuralları nasıl yazılır, nerede kaçak verir?
Bash kuralları önek eşleştirmesiyle çalışır (Bash(komut:*)), dosya kuralları ise gitignore tarzı dört desen tipini izler (mutlak, ev dizini, ayarlar-göreli, çalışma-dizinine-göreli). En sık kaçak, deny kuralının komutun adını engellemesi ama argümana gizlenmiş bir dosya yoluna veya soket erişimine dokunmamasıdır — dokümantasyon bunu allowUnixSockets üzerinden docker.sock erişimi örneğiyle açıkça isimlendirir. Bir deny kuralı yazdıktan sonra onu her zaman "bu komutun erişebileceği kaynağı da kapsıyor mu" sorusuyla test et.
Tüm izinleri atlamak (skip permissions) ne zaman kabul edilebilir?
bypassPermissions modu, tüm onay istemlerini atlar — bu yalnız izole, geri dönüşü olan bir ortamda kabul edilebilir: bir konteyner, tek kullanımlık bir sanal makine veya sandbox içinde çalışan bir CI görevi gibi. Ana geliştirme makinende, gerçek dosyaların ve gerçek kimlik bilgilerinin bulunduğu bir ortamda bu modu açmak, ajanın tek bir hatalı çıkarımının geri alınamaz bir sonuca dönüşmesi riskini taşır. Kural olarak: bypassPermissions'ı yalnız "bu makineyi kaybetsem hiçbir şey kaybetmem" diyebildiğin bir ortamda kullan.
Ajanı izole çalıştırmanın en pratik yolu nedir?
En pratik ve en az kurulum gerektiren yol, sandbox modunu /sandbox komutuyla açmaktır — bu, varsayılan olarak ajana yalnız çalışma dizinine yazma, diskin geri kalanına salt-okunur erişim ve proxy üzerinden denetlenen bir ağ erişimi verir. Daha güçlü bir izolasyon istiyorsan bunun üstüne bir devcontainer veya ayrı bir kullanıcı hesabı ekleyebilirsin; bu iki katman birbirini dışlamaz, tersine birlikte çalışırlar. Tek başına sandbox "bu dizinin dışına çıkma" der, konteyner ise "bu dizinin dışında zaten erişebileceğin bir şey yok" der.
Deny kuralı yazdım, hâlâ çalışıyor — neden?
Önce ayar hiyerarşisini kontrol et: kurumsal politika üstte, sonra komut satırı, yerel proje, paylaşılan proje, kullanıcı ayarları gelir — senin yazdığın kural daha alt bir seviyedeyse, üst seviyedeki bir allow kuralı tarafından geçersiz kılınmış olabilir (ya da tam tersi). İkinci kontrol noktası PreToolUse hook'ları: bu hook'lar izin sisteminden önce çalıştığı için, bir hook senin deny kuralından bağımsız olarak kendi mantığıyla onay verebilir. Üçüncüsü, dosya kuralı yazdıysan /yol biçimindeki kuralın ayar dosyasının dizinine göreli olduğunu, mutlak yol olmadığını kontrol et; mutlak yol için çift eğik çizgi (//yol) gerekir.
Güncelleme (Eylül 2026)
Bu yazının gövdesi 2025-12-10 tarihindeki izin sistemini anlatıyor; o tarihten bu yana sistemde önemli değişiklikler oldu. En büyük değişiklik, izin akışına yeni bir mod olarak "auto mode"un eklenmesi: bu modda her eylemi, kullanıcı yerine ikinci bir model (classifier) gözden geçiriyor ve Pro, Max, Team planlarında artık varsayılan başlangıç modu bu. 19 Eylül 2026'dan itibaren bu classifier, Claude API/Enterprise/Bedrock/Vertex/Foundry kullanıcıları için varsayılan olarak sunucu tarafında çalışıyor ve ek ücretlendirme yapılmıyor.
Kilitli CI ve script senaryoları için ayrı bir mod da eklendi: dontAsk, yalnız salt-okunur ve önceden onaylı araçların çalışmasına izin veriyor, prompt gerektirecek her şeyi otomatik reddediyor. Eski default modu ise artık CLI, editör eklentileri ve masaüstü uygulamasında "Manual" olarak etiketleniyor (CLI, manual'i default için bir takma ad olarak kabul ediyor).
Bu yazının "Deny kuralları neden kaçak verir" bölümünde anlattığım bileşik-komut açığı da bu dönemde kapatıldı: joker içeren izin kurallarının, kabuk operatörü (;, && gibi) içeren bileşik komutlarla eşleşebildiği güvenlik açığı Ocak 2026'da (v2.1.7) düzeltildi. Sandbox tarafında da benzer bir sıkılaştırma oldu — sandbox.excludedCommands glob deseni önceden bileşik bir komutun yalnız bir parçası eşleştiğinde komutun tamamını sandbox'tan muaf tutuyordu; Eylül 2026'daki düzeltmeyle artık muafiyet için komutun her parçasının eşleşmesi gerekiyor.
bash
1# Gözetimsiz (unattended) oturumlarda tehlikeli rm komutu artık2# 2 dakika cevapsız kalırsa otomatik reddediliyor; kapatmak için:3export CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1Sandbox'ın dangerouslyDisableSandbox kaçış kapısındaki sessiz atlatma hatası — sandbox dışında çalıştırılan bir komutun izin promptu olmadan geçebilmesi — Nisan 2026'da (v2.1.113) düzeltildi; ayrıca 22 Eylül 2026'da symlink üzerinden yapılan yazmalarda benzer bir açık kapatıldı: önceden bir symlink üzerinden gerçekte ağaç dışına çıkan bir yazma, acceptEdits veya auto mode tarafından yanlışlıkla otomatik onaylanabiliyordu. "İzin katmanları" bölümünde anlattığım "bir daha sorma" kuralı kaydetme davranışı da değişti: v2.1.211 öncesinde bir worktree'de verilen onay yalnız oturumun başlatıldığı dizine yazılıyordu; artık kural, ana checkout'un git kök dizinine çözümlenip tüm depoya (alt dizinler ve worktree'ler dahil) uygulanıyor.
Sonuç
Terminal ajanına izin vermek üç ayrı katmanı doğru sıraya koymaktır: önce mod (ne zaman sorulacağı), sonra kural (hangi istisnaların otomatik geçeceği), sonra sandbox (kuralın dışında kalan her şeyin fiziksel olarak nereye kadar erişebileceği). Bu disiplin, güvenli kimlik-bilgisi saklama ve performans profilleme alışkanlıklarında olduğu gibi, "önce dar başla, ihtiyaç çıktıkça genişlet" ilkesinin bir uzantısıdır. Bunu benimseyen bir ekip, spec-driven çalışma düzenini sandbox ile birleştirdiğinde, "izin verdim ama hâlâ kaçak var" sorununun büyük kısmını kapatır.
Kaynaklar
- Claude Code izin sistemi — 9 Aralık 2025 arşiv görüntüsü — izin modları tablosu, Bash/dosya kural sözdizimi, hook override ve beş seviyeli ayar hiyerarşisinin 2025-12-10 dönemindeki hâli.
- Claude Code sandboxing dokümantasyonu — 4 Kasım 2025 arşiv görüntüsü — varsayılan dosya/ağ izolasyonu davranışı ve üç somut güvenlik-sınırı riski (
allowUnixSockets,$PATH,enableWeakerNestedSandbox). - Anthropic — Claude Code'da sandboxing — 20 Ekim 2025 tarihli mühendislik yazısı, kurum-içi ölçümde izin promptu sayısının yüzde 84 azaldığı bulgusu.
- Claude Code permissions dokümantasyonu (güncel) — worktree kural kaydetme düzeltmesi ve
/permissionsdiyaloğunun anında uygulanması dahil güncel izin davranışı. - Claude Code permission modes dokümantasyonu (güncel) — auto mode,
dontAskmodu ve "Manual" etiketinin güncel tanımı. - Claude Code changelog — bileşik-komut deny kaçağı düzeltmesi (v2.1.7),
dangerouslyDisableSandboxsessiz atlatma düzeltmesi (v2.1.113) ve Eylül 2026 symlink/auto-mode düzeltmeleri. - npm registry — @anthropic-ai/claude-code — sürüm yayın tarihlerinin doğrulandığı birincil kaynak (2025-12-10 itibarıyla referans sürüm v2.0.64).
