Claude Code 2.1.316, yönetilen kuruluş ayarlarını onay istemeden uyguluyor

Yönetilen ayarlar için onay istemleri kaldırıldı

31 Ekim 2026'da yayımlanan Claude Code 2.1.316, kuruluşların yapılandırmayı geliştiricilerin makinelerine nasıl aktardığını değiştiriyor. Sürüm notlarına göre, Anthropic'in API'sinden çekilen ayarlar artık bir onay istemi olmadan yürürlüğe giriyor ve doğrulamadan geçemeyen önbellek kopyası reddediliyor. Gabriel Anhaia'nın dev.io'daki yazısı bu değişikliği ele alıyor; Classmethod'un sürüm kapsamı ise bunu kırıcı değişiklikler altında sınıflandırıyor.

Değişiklik Team ve Enterprise girişleri için geçerli. Yönetilen ayarlar, claude.ai yönetim konsolunda bir Owner veya Primary Owner tarafından belirlenen politikalalar; istemci bunları başlangıçta çekiyor ve güncellemeleri saatlik olarak yokluyor.

İletişim kutusu eskiden neyi kapsıyordu

Yönetilen politikanın çoğu hiçbir zaman onay gerektirmiyordu; istem yalnızca daha riskli bir alt kümeyi kapsıyordu. Anthropic'in dokümantasyonu, shell komutu çalıştıran ayarları (apiKeyHelper, statusLine ve otelHeadersHelper gibi); bir çalıştırılabilir dosyaya işaret eden ya da izolasyonu zayıflatan sandbox ayarlarını (sandbox.filesystem.disabled gibi); proxy ve base-URL ayarları gibi teslim edilen ortam değişkenlerini; ve herhangi bir hook tanımını listeliyordu. Bunların her biri daha önce çalışmadan önce etkileşimli bir oturumda bir iletişim kutusu gösteriyordu. 1 Kasım itibarıyla dokümantasyon sayfası, sürüme henüz yetişemediği için iletişim kutusunu hâlâ tarif ediyordu.

Anhaia, iletişim kutusunun hiçbir zaman gerçek bir veto olmadığına dikkat çekiyor: dokümanlar ayarları reddetmenin Claude Code'un çıkış yapmasına neden olacağını belirtiyordu ve claude -p ile Agent SDK oturumları gibi etkileşimli olmayan çalıştırmalar hiçbir şekilde iletişim kutusu gösteremiyordu; dolayısıyla onaya tabi ayarlar zaten o çalıştırmada uygulanıyordu. Kaybedilen şey, geliştiricinin yeni gelen bir hook'u ekranda adıyla görüp çalıştırılmadan önce fark ettiği o an, yani bildirimin kendisi.

Sürüm notunun diğer yarısı bir güvenlik düzeltmesi gibi okunuyor. Anthropic'in güvenlik tablosu daha önce, oynanmış bir önbellek ayar dosyasının bir sonraki sunucu çekimi değiştirene dek başlangıçta uygulanacağını belirtiyordu; doğrulamayan saklanmış bir kopyayı reddetmek bu boşluğu kapatıyor gibi görünüyor. Ne sürüm notu ne de changelog, doğrulamanın nasıl çalıştığını ya da istemin neden kaldırıldığını açıklıyor.

Ekipler teslim edilen ayarları nasıl inceleyebilir

Team ve Enterprise hesaplarındaki geliştiriciler artık yeni bir hook veya proxy değişkenini duyuracak bir iletişim kutusuna güvenemez; bu yüzden inceleme araçlara kayıyor. claude doctor komutu, teslim edilen ayarların yüklenip yüklenmediğini, kuruluşta hiç olmadığını ya da bir çekimin neden başarısız olduğunu ya da atlandığını gösteren bir managed-settings satırı raporluyor; 2.1.248 veya sonraki bir sürüm gerektiriyor. Bir oturum içinde /status hangi yönetilen kaynağın etkin olduğunu, /permissions ise yürürlükteki kuralları gösteriyor. Önbelleğin kendisi ~/.claude/remote-settings.json dosyasında yaşıyor; izlenecek anahtarlar hooks, apiKeyHelper, statusLine, otelHeadersHelper, sandbox altındaki her şey ve env bloğu.

Bir sınırlama var: dokümanlara göre ConfigChange hook'ları sunucu yönetimli ayarlar geldiğinde veya yenilendiğinde çalışmıyor; yani özel bir hook bu değişiklikleri izleyemiyor. Dokümanlar ayrıca yönetilen ayarları bir güvenlik sınırı değil istemci tarafı bir kontrol olarak tanımlıyor ve bu değişmedi. Yöneticiler ise hook eklerken geliştiricilere ekranda görünen bildirimi kaybediyor; Anhaia değişiklikleri doğrudan duyurmayı ve ayar değişikliklerini izlemek için uyumluluk API'sini veya denetim günlüğü dışa aktarımını kullanmayı öneriyor.

Subagent'lara kendi efor varsayılanı

Aynı sürüm, başka hiçbir şey belirlenmediğinde subagent'ların kullanacağı efor seviyesini belirleyen ve oturumun seviyesini devralmak yerine onu kullanan CLAUDE_CODE_SUBAGENT_EFFORT değişkenini ekliyor. Bu, yüksek eforla çalışan oturumlar için önemli: 2.1.316'dan önce xhigh eforla başlatılan bir oturum, kendi seviyesini belirtmeyen her subagent'a — derin akıl yürütmeye nadiren ihtiyaç duyan test çalıştırıcıları dahil — bu seviyeyi geçiyordu.

Classmethod bu ayrımı test etti: oturum yüksek efordayken değişken low olarak ayarlanırsa ana oturum yüksek, subagent düşük çalıştı; değişken olmadığında subagent yükseği devraldı. Değişken bir varsayılan, bir geçersiz kılma değil; çünkü bir subagent'ın frontmatter eforu ve çağrı başına değerler öncelik taşıyor. Bir açık soru duruyor: CLAUDE_CODE_EFFORT_LEVEL hem frontmatter hem çağrı başına eforu geçersiz kılıyor ve Classmethod, ikisi de ayarlıyken hangi değişkenin kazandığını dokümantasyonun söylemediğini belirtiyor.

Sürümdeki diğer değişiklikler

Sürüm notları ayrıca şunları listeliyor: --restricted oturumları için, daha önce bir Read izin kuralı kapsadığında çalışma dizinleri dışındaki dosyaları yükleyebilen oturumların düzeltilmesi; efor yükseltici anahtar kelimeyi kapatan CLAUDE_CODE_DISABLE_ULTRATHINK; arka plan işi tarafından uyandırılan subagent'ların ana modele kayması sorununun düzeltilmesi; 30 Ekim'de kullanımdan kaldırılan ve 30 Kasım 2026'da tamamen kaldırılacak, sonrasında isteklerin geri dönüş olmadan hata vereceği Opus 4.8 fast modunun kullanımdan kaldırılması; ve Claude apps gateway'deki gruplar için havuzlanmış aylık bütçeler.

Anhaia, 2.1.316'yı kendisinin çalıştırmadığını belirtiyor; anlatılan davranış, sürüm notlarına, dokümantasyona ve Classmethod'un testlerine dayanıyor.

Neden önemli

Kuruluşlar için, geliştiricinin gördüğü politika ile sessizce gelen politika arasındaki çizgi kaydı. Bir yönetici tarafından yapılandırılan hook'lar ve yardımcı çalıştırılabilir dosyalar artık geliştirici başına onay olmadan çalışıyor; pratik savunmaları yerel ayar önbelleğini denetlemeye, yönetici denetim güneklerini izlemeye ve yapılandırma değişiklikleri hakkında net iç iletişime kaydırıyor. Subagent efor değişkeni, yüksek eforlu akıl yürütmeye yaslanan oturumlar üzerinde ekiplere doğrudan maliyet kontrolü veriyor. Ve --restricted düzeltmesi, dosya erişimini kısıtlamak için bu bayrağa güvenenler için tek başına güncelleme yapmaya değer bir neden.