Korumaları yapılandırma

Bu kılavuz, korumaları nasıl yapılandıracağınızı gösterir: bir ajanın eyleminin çalışıp çalışmayacağına, önce onay isteyip istemeyeceğine yoksa reddedilip edilmeyeceğine karar veren kurallar.

Korumalar, değişiklik yapan her aracın bildirdiği on üç etki sınıfını kapsar. Araç çağrıldığı noktada sunucu tarafında denetlenirler; hiçbir zaman bir istemdeki talimatla değil.

Bir eylem sınıfı için karar belirleme

Ayarlar → Çalışma alanı → Ajan izinleri bölümüne gidin
Segmentli denetimle bir kapsam seçin: Çalışma alanı, Ajan (ardından ajanı seçin) veya Alan (ardından alanı seçin)
Eylem sınıfının satırında İzin ver, Önce sor veya Reddet’i seçin
Belirlediğiniz bir kuralı kaldırmak için o satırın sonunda görünen sıfırlama düğmesine basın (Devralınana sıfırla) — karar daha geniş kapsama geri döner

Her satır, geçerli kararı bir durum etiketi olarak ve nereden geldiğini gösteren bir rozetle birlikte gösterir: Bu kapsam, Devralınan veya Yerleşik varsayılan. Matris Ajan (chat) modunda çözümlenir, dolayısıyla Mod ön ayarı burada hiç görünmez — bu katmanı görmek için salt okunur bir mod seçiliyken Ne olur? sondasını kullanın.

Kural yazmak admin rolünü gerektirir. Matrisi okumak gerektirmez.

Kontrol noktası: çalışma alanı kapsamında Uzak depoya push et’i Reddet olarak ayarlayın, ardından aşağıdaki Ne olur? sondasını git push origin main üzerinde çalıştırın. Sonuç, workspace kaynağıyla deny olarak okunur.

Bir kararın nasıl çözümlendiğini anlama

Çözümleme önce özgüllük, sonra kısıtlayıcılık ilkesine göre yapılır:

Alan kuralları, sonra ajan, sonra çalışma alanı. Eşleşen bir kurala sahip ilk kapsam karar verir ve çözümleme durur
Hiçbir kural eşleşmezse mod ön ayarı geçerli olur — salt okunur bir mod (plan, inceleme, orkestrasyon) on üç sınıftan on birini reddeder
Modun söyleyecek bir şeyi yoksa yerleşik varsayılan geçerli olur

Tek bir kapsam içinde, bir komut kuralı en uzun eşleşen önekle çözümlenir ve eşit derecede özgül bir çakışma en kısıtlayıcı biçimde çözülür — Reddet, Önce sor’u; Önce sor da İzin ver’i yener. Birkaç sınıf bildiren bir eylem, her birini bağımsız olarak çözümler ve sonra hepsini en kısıtlayıcı biçimde birleştirir.

Bir Önce sor kararı, prompt olarak çözümlenen her sınıfı kapsayan tek bir onay istemi gösterir. Bağlı bir onaylayıcı yoksa reddedilir; bu hem shell komutları hem de harness araç çağrıları için geçerlidir. Bu bilinçlidir: kapısız bir çalıştırma, reddedilen bir çalıştırmadan daha kötüdür.

Eylem sınıfları ve yerleşik varsayılanlar

Eylem sınıfı	Yerleşik varsayılan
Dosya sil	Önce sor
Çalışma ağacının dışına yaz	İzin ver
Commit oluştur	İzin ver
Uzak depoya push et	Önce sor
Pull request aç	Önce sor
İnceleme yayınla veya birleştir	Önce sor
Harici takip sistemine yaz	Önce sor
Ağa eriş	İzin ver
Bir secret oku	İzin ver
Paket kur	İzin ver
Süreç çalıştır	İzin ver
Çalışma alanı yapısını değiştir	İzin ver
Bir enclosure’ı (rig) yönet	İzin ver

Sınıflandırma kapalıdır. Sınıflarını bildirmeden gönderilen yeni bir araç, CI’daki bir ratchet testinde başarısız olur; böylece hiçbir şey sessizce boş bir etki kümesiyle gelmez.

Bir kuralı Ne olur? sondasıyla sınama

Bir kuralı değiştirmeden önce, geçerli politikanın onu hâlihazırda nasıl çözümlediğini kontrol edin.

Aynı sayfada Ne olur? bölümüne kaydırın
Bir Eylem seçin (on üç sınıftan biri)
İsteğe bağlı olarak Komut (örneğin git push origin main), Ajan, Alan ve Mod alanlarını doldurun
Sonucu okuyun: karar, gerekçe ve Kaynak:

Sonda, denetim yolunun kullandığı aynı çözümleyiciyi geçerli kurallarınıza karşı çalıştırır, dolayısıyla yanıt kesindir. Sizi şaşırtırsa yukarıdaki matriste bir kuralı değiştirip yeniden sondayın.

Bir alanın özerklik kadranını ayarlama

Kadran alan başına ajan bazındadır ve kuralları değiştirmek yerine onlarla birlikte çalışır.

Alanı açın
Alan başlığından Katılımcıları yönet’i açın
Ajanın satırındaki Özerklik altında bir düzey seçin:

Düzey	Etki
Varsayılan	Alan ayarı yok — Onayla hareket et gibi davranır
Yalnızca öner	Kapıya tabi her araç doğrudan reddedilir; mesaj ajanı eylemi bunun yerine önermeye yönlendirir
Onayla hareket et	Riskli eylemler hata durumunda reddeden onay kapısına takılır
Serbest hareket et	Sabit bir reddet kararına çözümlenmeyen her şeyi önceden onaylar

Kadran yalnızca yerleşik harness’a ulaşır. Claude Code adaptörü kendi araçlarını bu kapının dışında çalıştırır.

Korumaların nereye ulaşmadığını bilme

Aynı sayfanın altındaki Kuralların uygulandığı yer tablosu bunun uygulama içi sürümüdür: her etki sınıfı için, her çalıştırıcının onu ilke kapısında yakalayıp yakalamadığını, sandbox’a bıraktığını veya hiç engelleyemediğini söyler.

Claude Code adaptörü kendi araç çağrılarında yalnızca kısmen kapıya tabidir. Claude Code --dangerously-skip-permissions ile başlatılır, dolayısıyla read, write ve edit çağrıları hiçbir zaman korumadan geçmez. bash komutları korumaya komut satırını sınıflandıran bir hook aracılığıyla ulaşır ve push’ları her ajanınki gibi push ağ geçidinden geçer. Geri çağırdığı MCP araç yüzeyi ve Control Center’ın onu başlatmak için çalıştırdığı shell komutu da kapıya tabidir.
Bir modun kendi çıktı fiili (submit_plan, propose_orchestration) sabitlenmiştir ve hiçbir zaman reddedilemez — aksi halde bir mod, tek çıktısını yapısal olarak üretemezdi.
Sandbox’ın bu kuralları destekleyip desteklememesi ana makineye bağlıdır. cc_server bir arka uç bulduğunda Claude Code CLI’sini ve harness bash aracını sarar; böylece sizin yazmadığınız bir kuralın bile altında bir işletim sistemi tabanı olur. Windows’ta hiç yoktur ve bwrap ile socat olmadan Linux veya WSL2’de de yoktur — orada korumalar ve modun araç yüzeyi denetimin tamamıdır; onun ikinci bir hattı değil. Hangi durumda olduğunuzu Sandbox politikalarını yapılandırma sayfasından kontrol edin.