Claude Code izinlerini .NET geliştirmesi için yapılandırmak

Claude Code'un izin kuralları, her dotnet komutunu aynı riskte görmeden nasıl yapılandırılır? Bu rehber kural sırasını, ayar kapsamlarını, wildcard risklerini ve veritabanı ile publish işlemleri için sınırları anlatıyor. Otomatik ya da headless çalışan .NET ajanları için okunmaya değer.

Kilit noktalar

• Kural değerlendirmesi deny, ask, allow sırasıyla yapılır; eşleşen bir deny veya ask, daha dar bir allow ile geçersiz kılınmaz.
• dotnet test, build ve publish komutlarını ask'ta tutun; Bash(dotnet *) gibi geniş aileleri pre-approve etmeyin.
• Ortak taban kuralları .claude/settings.json'a, kişisel ayarları .claude/settings.local.json'a koyun; token'ları bu dosyalara yazmayın.
• EF Core migration üretmek ile veritabanına uygulamak, build çıktısı üretmek ile deploy etmek ayrı yetkilerdir.
• Üretim kimlik bilgilerini geliştirme runner'larından çıkarın; sadece prompt veya CLAUDE.md'ye güvenmeyin.
• Komut engellendiğinde /permissions görünümüne ve aracın adına (Bash veya PowerShell) bakın.

Claude Code izinleri, kodlama ajanının hangi araçları sormadan kullanabileceğini belirler. Yazar, .NET işlerinde dotnet ile başlayan her komutu tek bir geniş izin ailesine koymanın yanlış olduğunu savunuyor. Kaynak okumak, dosya düzenlemek, test çalıştırmak, migration uygulamak ve yayımlamak farklı etkiler doğurur; bu yüzden her işlem, dokunduğu kaynak ve gerektirdiği kimlik bilgisi üzerinden değerlendirilmeli.

Rehber, belgelenmiş kural sırasını (deny, ask, allow), proje paylaşımlı ayarlardan yönetilen politikalara kadar ayar kapsamlarını ve wildcard eşleşmesinin sınırlarını ele alıyor. CLAUDE.md dosyasının yönerge olduğunu, zorunlu kılma mekanizması olmadığını hatırlatıyor. Headless çalışmalarda depo hook'larının ve MCP yapılandırmasının yüklendiğini de vurguluyor. Ana fikir, migration, deployment ve paylaşılan veriye erişimin ayrı kimlik bilgileriyle kapatılmasının daha güçlü bir sınır olduğu.

Gerçek dünyada kullanımı

• Bir ASP.NET Core endpoint'ini Claude Code ile düzenlerken dotnet test'e izin verip veritabanı güncellemesi ve publish komutlarını engellemek.
• Paylaşılan bir CI runner'ında --allowedTools Read ile bir Domain klasörünün headless özetini çıkarmak.
• Ekip ayarlarını miras alan bir EF Core çalışmasında otomatik işlem öncesi izin kurallarını gözden geçirmek.

Neden önemli

Bir .NET ekibi Claude Code izinlerini yönergeler, ortam kimlik bilgileri ve sunucu tarafı yetkilendirmeyle birlikte katmanlı düşünmeli. Onaylanan bir dotnet test, production veritabanına migration uygulama iznini kendiliğinden getirmez.

Benzer haberler

• .NET 8 ve 9 Destek Bitişi: Deployment Odaklı Geçiş Kontrol ListesiDVDEV Community: #dotnet2 gün önce
• Visual Studio Marketplace'e PAT olmadan güvenli yayın: Trusted PublishingMDMicrosoft for Developers Blog5 gün önce
• EF Migrations: Runtime yerine EF bundle ile güvenli dağıtımMLMostly Lucid (Scott Galloway)6 gün önce