· kaynak dev.to (home feed)
Solon'un Claude Code sandbox'unun Java portu, yapay zeka ajanı komutlarını işletim sistemi düzeyinde hapsediyor
dev.to'da yayımlanan bir anlatım, solon-ai-sandbox'ı tanıtıyor; bu modül, Claude Code'un sandbox-runtime'ının Java portu olarak ajan komutlarını macOS, Linux ve Windows üzerinde işletim sistemi tarafından zorunlu kılınan dosya sistemi ve ağ izolasyonuna sarıyor.

İşletim sisteminin zorunlu kıldığı bir sandbox
dev.to'da Solon Java projesinden çıkan bir anlatım, yapay zeka kodlama ajanlarının çalıştırdığı komutları gerçek dosya sistemi ve ağ izolasyonuna saran solon-ai-sandbox modülünü tanıtıyor. Gönderiye göre bu modül, Claude Code'un sandbox-runtime'ının Java portu ve macOS, Linux ile Windows üzerinde çalışıyor.
Öncül açık sözlü: ajana hassas dosyaları okumamasını söylemek gibi prompt düzeyindeki talimatlar, bir güvenlik sınırı değil, stokastik bir sürece yapılan rica-lardır. Bir ajan bir makinede shell komutları çalıştırabildiği anda, güvenilir biçimde işleyen tek kısıtlama, işletim sisteminin kendisinin dayattığı kısıtlamalardır.
Container yerine yerel izolasyon
Gönderi, sunucu tarafında çalışan ajanlar için container'ların hâlâ makul çözüm olduğunu kabul ediyor; ancak insanların etkileşimli olarak çalıştırdığı ajanlar — bir deponun çalışma kopyasını düzenleyenler — genellikle çevresinde container bulunmayan bir dizüstü bilgisayarda oturur. Her komut için bir VM ya da container başlatmak bu iş akışı için çok yavaştır ve ajanı, düzenlemesi gereken çalışma ağacından koparır.
solon-ai-sandbox orta yolu hedefliyor: ajanı proje dizininin içinde tutmak, bir derlemenin gerektirdiği registry'lere ve paket mirror'larına erişimine izin vermek ve container runtime devrede olmadan geri kalan her şeyi engellemek. Her platform kendi yerel aracını kullanıyor — macOS'ta üretilmiş bir Seatbelt profiliyle sandbox-exec, Linux'ta bubblewrap artı socat, Windows'ta ise Windows Filtering Platform katmanıyla srt-win.exe. Modülün tek bağımlılığı solon-ai-core.
Bir komutu sarma
API, süreç başına tek sandbox'a sahip, statik metotlardan oluşan final bir sınıf olan SandboxManager merkezli. Bir runtime yapılandırması ve isteğe bağlı bir etkileşimli geri çağırma (callback) ile başlatıldıktan sonra, tek bir çağrı — wrapWithSandbox — git status gibi bir komutu bash'e verilecek sarmalanmış bir shell dizgisine dönüştürüyor. macOS'ta bu bir sandbox-exec çağrısı üretiyor; Linux'ta ise uygun bind mount'lar ve namespace'lerle bir bubblewrap çağrısı. Uygulama kodu hiçbir zaman platforma göre dallanmıyor.
Asimetrik dosya sistemi kuralları
Dosya sistemi politikası okuma ve yazmayı bilinçli olarak farklı ele alıyor. Yazma yalnızca izin verilenlerle sınırlı: varsayılan olarak her şey reddediliyor, izin verilen yollar açıkça listeleniyor ve denyWrite bu listeden istisnaları geri çıkarıyor. Manager, /dev ve geçici dizinler gibi bir sürecin gerçekten ihtiyaç duyduğu yolları otomatik olarak veriyor; boş bir yazma izin listesi ise mümkün olan en katı ayardır.
Okuma mantığı tersine çevrilerek açık başlıyor, çünkü makine genelinde okumaları engellemek derleyicileri, JVM'yi ve userspace'in büyük kısmını bozar. Bunun yerine denyRead korumalı bölgeleri işaretliyor — gönderideki örnek ~/.ssh ve ~/.aws'i engelliyor — ve allowRead, bunların içindeki belirli yolları yeniden açabiliyor.
Yazar ayrıca .git içine yazmayı reddetmeyi öneriyor, çünkü kurcalanmış bir Git dizini iyi bir kalıcılık (persistence) mekanizması oluşturur; .git/config erişiminin ise varsayılan olarak kapalı, kendi allowGitConfig bayrağının ardında olduğuna değiniyor.
Proxy üzerinden ağ kontrolü
Ağ izolasyonu yerel bir HTTP ve SOCKS5 forward proxy olarak uygulanıyor. Sandbox içindeki süreç ortam değişkenleri üzerinden bu proxy'ye yönlendiriliyor ve her istek, *.github.com gibi wildcard desenleri destekleyen izin ve engelleme listelerine karşı denetleniyor. HostUtils adlı bir yardımcı, IPv4, IPv6 ve hostname biçimlerini normalize ediyor; böylece eşleştirme, bir adresi farklı biçimde yazarak atlatılamıyor.
Proxy tasarımı canlı güncelleme sağlıyor: SandboxManager.updateConfig, halihazırda çalışan ajan süreçleri dahil, bir sonraki istekte etkili oluyor. Dosya sistemi kuralları aynı şekilde sıcak değil — macOS'ta bir komut sarılırken Seatbelt profiline derleniyorlar, Windows'ta ise açıkça yeniden damgalanmaları gerekiyor — bu yüzden onları değiştirmek reset() çağrısı yapıp yeniden başlatmak anlamına geliyor. Bir ask geri çağırması, bir insanın hostname desenlerini etkileşimli olarak onaylamasına izin veriyor; gönderiye göre geri çağırma istisna fırlattığında ya da bir isteği hiçbir kural kapsamadığında bağlantı reddediliyor.
İki keskin kenar
Gönderi iki pratik tuzağa dikkat çekiyor. Birincisi, README hâlâ on iki argümanlı bir SandboxRuntimeConfig constructor'ı gösteriyor, oysa Solon AI 4.1.x ağacındaki güncel kaynak kodu on üç argüman bildiriyor ve sonuncusu bir WindowsConfig; README'den kopyalanan kod derlenmeyecek. İkincisi, Windows'ta dizgi döndüren wrapWithSandbox bir komut döndürmek yerine istisna fırlatıyor; dolayısıyla o platform farklı bir çağrı gerektiriyor.
Neden önemli
Kodlama ajanları giderek kullanıcının kendi yetkileriyle çalışıyor; bu, "ajan benim yapabildiğimi yapabilir" ile "ajan benim izin verdiğimi yapabilir" arasındaki boşluğu, etki alanını (blast radius) sınırlayan en büyük etken yapıyor. Bu modül, etkileşimli ajanların gerçekten yaşadığı dizüstü iş akışına uyan, container runtime olmadan işletim sisteminin dayattığı hapsetme biçiminde işler bir örnek sergiliyor. Claude Code'un sandbox-runtime'ından gelmesi de sandbox'ın tek satıcılı bir özellik değil, ekosistemler arası paylaşılan bir altyapı hâline geldiğine işaret ediyor. Ve uyarılar da özelliğin kendisi kadar öğretici: asimetrik varsayılanlar, farklı hızlarda güncellenen kurallar ve kaynaktan çoktan kopmuş belgeler, erken benimseyenlerin ilk olarak tam olarak karşılaşacağı ayrıntılar.
- #ai-agents
- #java
- #security
- #sandboxing
- #developer-tools