Gözetimsiz Claude Code: çalışma alanı sınırları, başsız mod ve görev kabulü

1. Bir görevi gözetimsiz bırakmadan önce başarıyı tanımlayın

Yararlı bir gözetimsiz görev, “depoyu düzelt” talimatından daha belirgindir. Girdi sürümünü, izin verilen dizinleri, araçları, beklenen çıktı dosyasını, azami süreyi ve insan kararı gerektiren koşulları yazın. Örneğin bir belge görevi, sağlanan değişiklik farkını okuyup ağ araçları veya kaynak değişiklikleri olmadan çıktı dizinine rapor üretebilir. Böyle bir sözleşmeyi bağımsız bir denetleyici değerlendirebilir.

Üç sonucu ayırın: çalıştırıcı başladı, Claude bir sonuç döndürdü ve istenen iş kabul kontrolünden geçti. Süreç doğru başlayıp daha sonra bir aracı reddedebilir. Akıcı JSON döndürürken dosyayı değiştirmeyebilir. Yararlı işi bitirirken bir alt süreci açık bırakabilir. Hepsini tek yeşil göstergeye dönüştürmek, hataların nedenini anlamayı güçleştirir.

Aşağıdaki plan, sizin yönettiğiniz çalıştırıcı ve tek kullanımlık veriler içindir. Kurulu sürümünüzün, kimlik bilgilerinizin veya şirket politikanızın aynı şekilde davrandığını kanıtlamaz. Testten önce sürümü ve etkili yapılandırmayı kaydedin. İlk olarak zararsız ve geri alınabilir bir iş seçin; kurtarmanın somut olması için önceki başlatıcı yapılandırmasını saklayın.

2. 30 ve 31 Ekim'de ne değişti?

Resmî GitHub üst verisine göre v2.1.314, 30 Ekim 01:06:26 UTC'de; v2.1.316, 31 Ekim 01:01:35 UTC'de yayımlandı. Bunlar Singapur'da sırasıyla 09:06:26 ve 09:01:35'tir. Araştırmada resmî son sürüm uç noktası hâlâ v2.1.316'yı gösteriyordu. Bunlar yayın zamanıdır; her kurulumun güncellendiğini kanıtlamaz.

Mühendislik fırsatı, çalıştırıcı ile ajan arasındaki sözleşmeyi netleştirmektir. Belgelenmiş bir düzeltme, ekleyebileceğiniz regresyon örneğidir; ilgili bütün hataların imkânsız olduğunu göstermez. Eski arka planı açıkça tarihlendirin: aşağıda ele alınan MCP tekrar ve güvenlik olayı değişiklikleri yeni bir kasım duyurusu değil, 21 Ekim UTC sürümündendir.

3. Dosya araçlarını, komutları ve dış hizmetleri ayrı haritalayın

En az dört yürütme yolu vardır: yerleşik dosya araçları, kabuk komutları ve alt süreçleri, yerel entegrasyon süreçleri ve uzak hizmetler. Çalışma dizini kuralı ilkini yönetirken Python test sürecini veya MCP sunucusundaki veritabanı işlemini sınırlamayabilir. Worktree, Git çalışmalarını ayırır; oradan başlatılan her şeyin çevresine işletim sistemi sınırı koymaz.

Sandbox belgesi, kabuk yalıtımını dosya ve web araçlarından, yerel MCP sunucularından, kancalardan ve yardımcı süreçlerden açıkça ayırır. Uzak araç tamamen başka makinede çalışabilir. İzinleri belirlemeden önce kısa envanter çıkarın: yazmayı hangi süreç yapıyor, hangi kimlik bilgisini kullanıyor ve onu hangi bileşen durdurabiliyor?

Yalnızca rapor üreten bir işte gereksiz yürütme yolunu kaldırmak, onu açıp birçok istisna yazmaktan daha kolay doğrulanabilir. Bu bir mimari tercihtir; az araç kullanmanın her girdiyi güvenilir yaptığı sözü değildir. Araç envanterini, izinleri ve çalışma zamanı yalıtımını iş yapılandırmasında ayrı alanlar olarak tutun.

4. Yeni yazma sınırını, eksik başvuru ayrıntılarını uydurmadan kullanın

Sürüm notu, permissions.blockWritesOutsideWorkingDirectories anahtarını adlandırır; Write, Edit ve NotebookEdit'in her izin modunda çalışma dizinleri dışındaki yolları reddettiğini söyler. Bu, adı verilen araçlar hakkında anlamlı bir ifadedir. Rastgele komutları, uzak hizmetleri veya oturumdan bilgi çıkarmanın her yolunu kapsayan bir garanti değildir.

İncelediğimiz resmî ayar başvurusunda yeni anahtar için özel bir kayıt yoktu. Bu yüzden tahmin edilmiş eksiksiz yapılandırma, varsayılan değer, uzaktan aktarma kuralı veya ek dizin uç durumu sunmuyoruz. Kullanacağınız sürümde ayarın geçerli olduğunu ve gerçek reddi test etmeden ona güvenmeyin. Sessizce yok sayılan bir anahtar, aksi hâlde sahte güven oluşturur.

Araç adlarını yol kuralı sözdiziminden de ayırın. İzin başvurusu, yol kapsamlı düzenleme kurallarının Edit(path) kullandığını; Write(path) veya NotebookEdit(path) kuralının dosya kontrolleriyle eşleşmediğini belirtir. Çözümlenen kuralı ve kaynağını inceleyin. Gerçek ev dizini dosyalarını kullanmadan içerideki, komşu ve bilerek eklenmiş geçici dizinleri test edin.

5. Kabuk yalıtımını, kullanılabilirliği ve geri dönüşü doğrulayın

Kabuk testi yalnızca Edit çağrısını değil, alt süreci sınamalıdır. Onaylı derleme, dosyaları dolaylı açan betikler çalıştırabilir. Dosya kuralları belgesi bu sınırlamaları anlatır; çalışan alt süreci işletim sistemi sınırı kısıtlar. Yerleşik sandbox macOS, Linux ve WSL2'yi destekler. Yerel Windows, JSON ayarı var diye aynı sınırı kazanmaz.

Desteklenen tek kullanımlık çalıştırıcılarda resmî yönetilen sandbox örneği şu ayarları birleştirir. Bu, incelemek için yapılandırma biçimidir; kurduğumuz veya çalıştırdığımız bir ayar değildir:

{"sandbox":{"enabled":true,"failIfUnavailable":true,"allowUnsandboxedCommands":false}}

Bu seçenekler yalıtımın kullanılamamasını ve sandbox dışı tekrarları ele alır. Her hariç tutulan komutu ya da kabuk sandbox'ı dışındaki süreci kapsamaz. Varsayılan okuma, kimlik bilgileri dahil makinenin büyük bölümüne erişebilir; yazma kadar okumayı ve devralınan ortamı da inceleyin. Bütün araç zinciri sınırlanacaksa tüm süreci uygun yalıtılmış çalıştırıcıda yürütün; bağlanan dizinleri ve ağ yollarını denetleyin.

Yapılandırmayı görmek için /sandbox kullanın. Zararsız test komutunu ajanın aracı çalıştırsın; alışılmış ! istemine kendiniz yazmanız farklı, yalıtılmamış yolu sınayabilir. macOS testi, bağımlılıkları eksik bir WSL imajını doğrulamaz.

6. Başsız çalıştırmanın neleri keşfedebileceğine karar verin

Print modu bir yürütme arayüzüdür, otomatik güven sınırı değildir. Normal claude -p çalışma alanı güven iletişim kutusu göstermez; proje kancalarını ve MCP yapılandırmasını keşfedebilir. ultrareview ve remote-control için 30 Ekim CI düzeltmesini bu farklı yola genellemeyin. Üçüncü taraf depoyu çağırmadan önce deponun sağlayabileceği yürütmeyi inceleyin.

--bare, özelleştirmelerin otomatik keşfini azaltır. İşletim sistemi yalıtımı sağlamaz; belgeler istisnaları ve ayar kaynağı etkileşimlerini açıklar. Anthropic API için bare modu abonelik girişi yerine API kimlik bilgisi kullanır. Dolayısıyla kimlik doğrulama ve faturalandırma yolu açık dağıtım kararı olmalıdır; buradaki örnekler model isteği göndermedi.

CLI başvurusu, eşleşen çağrıları önceden onaylayan --allowedTools ile yerleşik araç kullanılabilirliğini sınırlayan --tools arasında ayrım yapar. İkincisi MCP araçlarını kaldırmaz. --setting-sources, açık ayarlar ve MCP yapılandırmasını birlikte inceleyin. Kurumsal zorunluluk için yerel bayrağın politikayı geçersiz kıldığını varsaymak yerine yönetilen ayarları kontrol edin. Başlatıcıyı ve incelenen yapılandırmayı aynı sürümlü pakette tutun.

7. MCP envanteri, kimlik bilgileri ve tekrar güvenliğini ayırın

MCP bağlantısı ayrı bir yetenektir. Her sunucuyu, aktarım türünü, izinli aracı ve iş eylemini listeleyin. Yerel sunucu ana makine erişimiyle başlayabilir; uzak sunucu Claude'un görmediği kimlik bilgilerine sahip olabilir. Ajan tarafındaki dosya kuralını veritabanı veya iş takip sistemi politikası saymak yerine sunucunun kendi erişimini ve görev kapsamını daraltın.

MCP başvurusu, araç salt okunur veya idempotent olduğunu bildiriyorsa kesilen bekleyen HTTP çağrısının bir kez yinelenebileceğini açıklar. Önceki v2.1.307 sürümü bu düzeltmeyi 21 Ekim UTC'ye tarihler. Bildirim, gerçek bir ödemeyi, mesajı veya kaynak oluşturmayı tekrarlamanın güvenli olduğunun kanıtı değildir. Hizmetin gerçek tekrar davranışını uygulayın ve uygun olduğunda işlem kimliğiyle test edin.

Kabul için yerel bir taklit hizmet günlüğü kullanın. Bilerek kesilen yanıtın ardından gelen çağrıları ve son durumu sayın. Başarılı tekrar, tam bir kez teslimi kanıtlamaz. Gerçek müşteri iş akışını test verisi olarak kullanmayın. Günlüğe kimlik bilgisi yazmayın; süre dolmasını üretim oturumunu bozarak değil, tek kullanımlık test kimliğiyle sınayın.

8. Çıkış durumunu, JSON'u ve çıktı dosyasını eşleştirin

Başlangıç düzeltmesi, eskiden yanıltıcı olan hatayı görünür kılar. Sarmalayıcı yine çıkış kodunu, stdout, stderr, süreyi ve görev kimliğini ayrı toplamalıdır. Sıfır kod, süreç sonucu hakkında kanıttır; istenen depo değişikliğinin doğruluğunu bağımsız olarak kanıtlamaz.

Yapılandırılmış çıktı, JSON'u ve verilen şemayı destekler. Tüketmeden önce structured_output alanının varlığını kontrol edin; belge, çalıştırmanın bu alan olmadan bitebileceğini belirtir. Şema doğrulama biçimi denetler. Dosyanın var olduğunu, testin gerçekten çalıştığını veya bildirilen iş durumunun kaydedildiğini göstermez.

Bağımsız denetleyiciye beklenen çıktı yolunu ve belirlenebilir koşulları verin. Rapor işi, bilinen test başvurularını içeren UTF-8 dosyası isteyebilir; kod görevi kendi uygun kontrollerine ihtiyaç duyar. Değişiklikleri izinli dosya kümesiyle karşılaştırın, beklenmedik düzenlemeleri reddedin. Reddedilen eylemi aktarım hatasından ayırın ve ajanın açıklamasını saklayın, ancak dosya kontrolünün yerine koymayın.

9. Süreyi sınırlayın ve iptalden sonra temizliği doğrulayın

Model döngüsünün dışında bir çalıştırıcı son tarihi koyun. Başlatıcının kapanmayı nasıl isteyeceğini, ne kadar bekleyeceğini ve yalnızca bu işe ait süreçleri nasıl tanıyacağını belirleyin. Zaman aşımı görevin son durumudur; aynı işi sonsuza kadar çalışır bırakma izni değildir. Geniş ad eşleştirmeleriyle ilgisiz süreçleri sonlandırmayın.

31 Ekim temizleme düzeltmesi, Claude Code macOS ve Linux'ta kendiliğinden çıktığında geride kalan kabuk komutlarıyla ilgilidir. Her ayrılmış alt sürecin temizliğini veya uzak MCP hizmetine gönderilmiş işin iptalini kanıtlamaz. İkisi de ayrı gözlem gerektirir.

Tek kullanımlık testte alt süreç yalnızca test dizinine kalp atışı yazabilir. İptalden sonra yazmanın durduğunu ve işe ait sürecin bittiğini gözleyin. Uzak asenkron görevleri de taklit hizmetle ve son durumlarıyla sınayın. İptal desteklenmiyorsa bu sınırı kaydedin, yan etkileri kabul edilebilir iş seçin. Tamamlanmamış çıktıları açıkça başarısız işaretleyin; sonraki işler bunları bitmiş sayıp yayımlamasın.

10. Her şeyi toplamadan reddi açıklayan kanıt biriktirin

Görevi, sürümü, yapılandırma revizyonunu, çözümlenmiş çalışma alanını, izinli araçları, sonucu ve denetleyici kararını kaydedin. Böylece “sınır çalıştı”, “model denemedi” ve “toplayıcı olayı kaybetti” ayrılır. Ret günlüğü ancak denenen işlem ve bağımsız son durumla bağlanabildiğinde değerlidir.

Claude Code'un izleme başvurusu, v2.1.307'den itibaren claude_code.safety_event olayını belgeler; ancak bu olayı üretmeyen çağrıları da listeler. Kendi alanları ham komut ve yol ayrıntılarını içermez; standart nitelikler çalışma alanı bilgisini taşıyabilir ve isteğe bağlı ayrıntılı araç günlüğü içerik ekler. Bütün akışı anonim saymayın, her reddin temsil edildiğini varsaymayın.

Asgari üst veri ve az sayıda sentetik olayla başlayın. Toplayıcı hedefini ve saklama politikasını koruyun. Bir olayın yokluğunu kanıt saymadan günlüklerin geldiğini doğrulayın. Bu CLI araç kararı kanıtı API maliyet analizinden farklıdır; sınırları açıklamaya yarar, faturayı uzlaştırmaya veya bütün dış yan etkileri kanıtlamaya değil.

11. Tek kullanımlık kabul matrisi uygulayın

workspace/, sibling/ ve results/ içeren yeni bir geçici üst dizin oluşturun. Sibling içine zararsız kontrol metni koyup özet değerini kaydedin. Tüm hedefler bu dizinde kalsın; gerçek kimlik bilgileri, ev dosyaları veya müşteri sistemleri kullanmayın. Aşağıdaki plan bizim önerimizdir, bu yazı için çalıştırılmadı.

Olumsuz örnekleri başarılı yol kadar ciddiye alın. Önceki ve sonraki özetleri, tam başlatıcı parametrelerini ve politika kaynağını saklayın. Her varyantta yeni test verisi kullanın. Önceden genişletilmiş çalışma alanı, fazla kapsamlı ek dizin kuralını gizleyip yanıltıcı başarı üretebilir.

12. Yapılandırma paketi yayımlayın, sonra iş yükünü genişletin

CLI sürümünü, başlatıcıyı, model seçimini, ayar kaynaklarını, yönetilen politika beklentisini, MCP envanterini, süre kuralını ve denetleyiciyi paketleyin. Revizyon ve geri dönüş hedefi verin. Eşleşen yapılandırma olmadan bağımlılık güncellemek, keşfi geri getirebilir veya sarmalayıcının hata yorumunu değiştirebilir.

Rapor üreten ya da benzer şekilde geri alınabilir işlerle başlayın. Her hedef işletim ortamında gerekli testler geçtikten sonra paketi ilerletin ve sınırlı gerçek iş gözleyin. Durdurma koşullarını önceden yazın: dışarıdaki çıktı değişiyor, açıklanamayan süreç yaşıyor, idempotent olmayan işlem tekrarlanıyor veya zorunlu yapılandırma doğrulanamıyor.

Kalan bilinmeyenler somut yayın kapılarıdır: yeni yazma anahtarının eksik başvuru ayrıntıları, makine davranışı, uzak iş iptali ve telemetri bütünlüğü. Resmî not bir değişikliği ortaya koyar; kaydettiğiniz testler yalnızca sınanan yapılandırma ve iş yükünü gösterir. Sonuçları paylaşırken kapsamı koruyun, CLI, sarmalayıcı, politika veya entegrasyon değişince ilgili örnekleri tekrarlayın.