Paylaşılan bir settings.json, Claude Code izinlerini ekipler için varsayılan olarak güvenli kılıyor

dev.to'da yayımlanan bir rehber, Claude Code benimseyen ekiplerin karşılaştığı bir ölçeklenme sorununu ele alıyor: tek başına çalışan bir geliştirici için kişisel alışkanlık olarak işleyen izinler, bir grup içinde tutarsız ve denetlenemeyen agent davranışına yol açıyor. Önerilen çözüm, depoya işlenen paylaşımlı bir izin dosyası; böylece her geliştiricinin oturumu aynı kurallarla başlıyor.

Rehber — sonunda tanıttığı bir workspace kurulum aracının yapımcıları tarafından yazıldı — sorunu açıkça tarif ediyor: tek başına çalışan geliştiriciler kendi onay kalıplarına yerleşiyor, ekip arkadaşları başkalarının agent'ının neyi çalıştırmaya yetkili olduğunu göremiyor ve yeni çalışanlar, hangilerinin önemli olduğunu bilmeden ilk gün prompt'ları tıklayıp geçiyor.

Hangi dosya ne işe yarar

Rehbere göre Claude Code'un ayar konumlarının üçü ekipler için önemli. Depo düzeyindeki .claude/settings.json, depoda çalışan herkese uygulanır ve depoya işlenmesi gereken dosya budur. .claude/settings.local.json dosyası bir geliştiricinin o depoya özel kişisel istisnalarını tutar ve git dışında kalır — Claude Code bu dosyayı kendisi oluşturduğunda otomatik olarak hariç tutar, ancak elle oluşturulan bir kopya .gitignore girdisi ister. Kullanıcı düzeyindeki ~/.claude/settings.json ise bir geliştiriciye tüm projelerde uygulanır ve asla depoya girmez. Kimsenin geçersiz kılamayacağı kurallara ihtiyaç duyan organizasyonlar, üçünün de üstünde duran managed settings'i ek olarak kullanabilir.

Allow, ask, deny

Önerilen paylaşımlı dosya bilinçli olarak kısa: sürekli çalıştırılan ve zarar veremeyecek komutlar için bir allow listesi — lint, testler, tip kontrolleri, salt okunur git; sorunsuz ama insan gözü hak eden eylemler, örneğin push, publish veya yerel bir migration çalıştırmak için bir ask listesi; ve secret okumaları ile ekibin agent'ın asla çalıştırmasını istemediği komutlar için bir deny listesi.

Farklı dosyalardaki listeler yerine konmadan birleştirilir: geliştiricinin kişisel allow kuralları ekibin listesine eklenir, ancak ekibin deny kurallarını kaldıramaz.

Deny kuralları kazanır

Claude Code önce deny kurallarını, sonra ask, sonra allow kurallarını değerlendirir ve bu sıradaki ilk eşleşme kararı verir; kuralın özgüllüğü kontrolün sırasını değiştirmez. Rehbere göre bunun sonucu, bir allow kuralının bir deny kuralından istisna yaratamamasıdır: ekip dosyası Bash(aws *) komutunu deny ediyorsa, bir geliştirici yerel allow listesine Bash(aws s3 ls) ekleyebilir ama yine engellenir. Bu öncelik, paylaşımlı dosyayı güvenilir kılan şeydir; çünkü ekip deny kuralları, herkes yerel olarak ne eklerse eklesin ayakta kalır.

Kurallar komutlarla nasıl eşleşir

Bir kuralın yazarının amaçladığını yapıp yapmadığını birkaç ayrıntı belirler:

• *, kendi konumundaki her metinle eşleşir; dolayısıyla Bash(npm run test *) bu komutu her argümanla kapsar.
• Sondaki *'dan önceki boşluk önemlidir: Bash(ls *) ifadesi ls ve ls -la ile eşleşir ama lsof ile eşleşmez; Bash(ls*) ise lsof ile de eşleşir.
• Bileşik komutlar parçalara bölünür. Bash(npm run test *) izni vermek npm run test && rm -rf build komutunu onaylamaz; her parçanın kendi başına izinli olması gerekir ve herhangi bir parça bir deny kuralıyla eşleşiyorsa deny uygulanır.
• Dosya kuralları yol kullanır: Read(./.env) tek bir dosyayı, Read(./secrets/**) ise bir klasörün altındaki her şeyi kapsar.

İzin kuralları nerede biter

Rehber, izin kurallarının agent davranışını şekillendirdiğini ama tek başına bir güvenlik sınırı olmadığını açıkça belirtiyor. Bir Bash kuralı, agent'ın yazdığı komut metniyle eşleşir; dolayısıyla aynı programın bir değişken, bir script veya sh -c üzerinden çağrılması eşleşmeyebilir; rehber, curl'ü tek bir domain'le sınırlamak gibi komut argümanlarını kısıtlayan kuralların kırılgan olduğuna dair uyarı yapan Claude Code'un kendi dokümantasyonuna atıf yapıyor. Gerçek garanti için katmanlama öneriyor: komutun nasıl yazıldığına bağlı olmayan dosya sistemi ve ağ sınırları için sandbox; her komuttan önce özel bir kontrol çalıştırıp onu engelleyebilen ve aynı paylaşılan ayar dosyasında saklandığı için tüm ekibin miras aldığı PreToolUse hook'ları; ve agent üretim ortamına asla dokunmamalıysa geliştiricinin makinesinde üretim kimlik bilgilerinin bulunmaması ilkesine dayanan sıradan erişim kontrolü.

Yayına alma

Önerilen dağıtım küçük başlıyor: secret'lar için deny kuralları, test ve lint için allow kuralları; tek başına bu bile prompt'ların çoğunu ve en riskli okumaları ortadan kaldırıyor. Dosyayı normal bir pull request üzerinden işleyin ki ekip onu kod gibi incelesin, haftada iki kezeden fazla onaylanan her prompt'u paylaşımlı allow listesi için aday olarak görün ve hangi ayar kaynaklarının yüklendiğini doğrulamak için Claude Code'ta /status komutunu çalıştırın. Rehberin kapanış tavsiyesi, ayarlar dosyasındaki değişiklikleri CI yapılandırmasıyla aynı özenle incelemek; çünkü bu dosya, her geliştiricinin agent'ının sormadan neler yapabileceğini belirliyor.

Neden önemli

Agentic kodlama asistanları bireysel denemelerden ekip standardı araçlara doğru ilerliyor ve izin prompt'ları bunların birincil güvenlik etkileşimi. Depoya işlenen, incelenen bir ayar dosyası bu prompt'ları kişisel kas hafızasından sürümlü yapılandırmaya dönüştürüyor ve deny-kazanır önceliği sayesinde garantiler yerel özelleştirmeye rağmen ayakta kalıyor. En az bunun kadar dikkat çekici olanı sınırlar hakkındaki açıklık: izin listeleri tutarlılık ve daha az kesinti sağlar, güvenlik değil; gerçek garantiler için hâlâ sandbox, hook ve kimlik bilgisi hijyeni gerekiyor. Claude Code'a standartlaşan ekipler için paylaşılan bir ayar dosyası düşük çaba, yüksek kaldıraçlı bir ilk adım.