Claude Code'u tehlikeli (güvenli) şekilde çalıştırmak

• Claude Code'un --dangerously-skip-permissions bayrağını güvenli şekilde kullanma yöntemi
• Docker, VM, Firejail gibi çeşitli izole çalıştırma ortamları incelendikten sonra en uygun seçeneğin Vagrant tabanlı sanal makine (VM) olduğuna karar veriliyor
• Vagrant ile tam VM izolasyonu, tekrarlanabilir kurulum ve yerel klasör paylaşımı korunurken Docker-in-Docker sorunlarından kaçınılıyor
• Claude Code'un VM içinde sudo yetkisiyle sistemi serbestçe yönetmesi sağlanıyor; pratikte web uygulaması çalıştırma, veritabanı yapılandırma ve test otomasyonu gibi işler yapılıyor
• Bu yöntem, yanlışlıkla oluşabilecek dosya sistemi hasarını önlemede etkili; gerektiğinde VM silinip yeniden oluşturularak güvenli biçimde sıfırlanabiliyor

---

Arka plan

• Claude Code kullanırken her seferinde izin isteğini onaylama zahmetini ortadan kaldırmak için --dangerously-skip-permissions bayrağını kullanma denemesi yapılıyor
  • Bu bayrak, paket kurulumu, ayar değişikliği, dosya silme gibi tüm işlemleri ön onay olmadan otomatik olarak gerçekleştiriyor
  • İş akışını bölmediği için verimli, ancak dosya sistemi hasarı riski taşıyor
• Bunu önlemek için, host işletim sistemi hesabından ayrılmış bir ortamda çalıştırma gereği fark ediliyor

Değerlendirilen yöntemler

• Önce Docker ile izolasyon değerlendiriliyor, ancak Claude'un Docker imajı oluşturup container çalıştırması gerektiğinden Docker-in-Docker yapılandırması gerekiyor
  • Bu durumda --privileged modu gerektiği için sandbox amacının anlamı kalmıyor
  • Ağ katmanının iç içe geçmesi, volume mount izin sorunları gibi nedenlerle karmaşıklık ve kararsızlık artıyor
• Diğer alternatifler olarak şunlar değerlendiriliyor
  • Bare metal çalıştırma: Reddit örneklerinde veritabanı veya home dizininin silinmesi gibi ciddi hasar vakaları var
  • sandbox-runtime: ACL tabanlı erişim kontrolü sunuyor; Claude kod dışına erişemiyor ama tam özgürlük sağlamıyor
  • Firejail: Docker'a benzer kısıtlar var
  • Manuel VM kurulumu: tekrarlanabilirlik zayıf
  • Bulut VM: maliyet, gecikme ve kod yükleme gereksinimi sorunları var

Vagrant tabanlı yaklaşım

• Vagrant kullanılarak tam VM izolasyonu ve tekrarlanabilir kurulum sağlanıyor
  • Paylaşılan klasörler sayesinde yerel ortamdaymış gibi erişim mümkün
  • Docker-in-Docker sorunu yok; gerektiğinde VM kolayca silinip yeniden oluşturulabiliyor
• VirtualBox 7.2.4 sürümünü kullanırken CPU'nun %100 kullanılması hatası keşfediliyor; neden GitHub issue üzerinden doğrulanıyor
• Nihai Vagrantfile yapılandırması şu özelliklere sahip
  • bento/ubuntu-24.04 temel imajı kullanılıyor
  • 4 GB bellek, 2 CPU ayrılıyor
  • Docker, Node.js, npm, git, unzip kuruluyor
  • @anthropic-ai/claude-code global olarak kuruluyor
  • vagrant kullanıcısı Docker grubuna ekleniyor

Gerçek kullanım biçimi

• Proje dizininde sırasıyla vagrant up → vagrant ssh → claude --dangerously-skip-permissions çalıştırılıyor
• İlk açılışta provisioning birkaç dakika sürüyor ve her proje için yalnızca bir kez Claude girişi yapmak gerekiyor
• İş bitince vagrant suspend ile VM askıya alınabiliyor
• Claude'a VM içinde sudo yetkisi veriliyor ve şu işleri yapabiliyor
  • Web uygulaması API'sini çalıştırıp curl ile kontrol etme
  • Tarayıcı kurup uygulamayı manuel inceleme ve E2E testleri oluşturma
  • PostgreSQL veritabanını yapılandırma ve migration testleri yapma
  • Docker imajı oluşturma ve çalıştırma
• Bu ortam sayesinde Claude, komut çalıştırma, çıktıyı kontrol etme ve yinelemeli süreci kendi başına yürütebiliyor

Performans ve güvenlik

• Linux + VirtualBox ortamında kaynak fazlasıyla yeterli ve dosya senkronizasyonunda gecikme yok
• Koruyabildiği şeyler
  • Yanlışlıkla oluşabilecek dosya sistemi hasarı
  • Kontrolsüz paket kurulumu ve ayar değişiklikleri
• Koruyamadığı şeyler
  • Proje klasörünün silinmesi (çift yönlü senkronizasyon)
  • VM escape zafiyetlerinin kötüye kullanılmasıyla yapılan saldırılar
  • Ağ seviyesindeki sorunlar
  • Veri sızıntısı (VM internete erişebiliyor)
• Bu yapılandırma kazaları önlemeye yönelik; ileri düzey saldırılara karşı savunma amacı taşımıyor
• Proje Git tabanlı olduğu için hasar durumunda kurtarma kolay; gerekirse rsync ile tek yönlü senkronizasyon kullanılarak daha katı bir izolasyon sağlanabiliyor

Sonuç

• VirtualBox CPU hatası çözüldükten sonra sürtünmesiz bir çalışma ortamı tamamlanıyor
• Claude Code, tam bir VM sandbox'ı içinde serbestçe çalıştırılabiliyor
• Sorun çıkarsa VM silinip yeniden oluşturulabiliyor ve tek bir Vagrantfile ile tekrarlanabilirlik sağlanıyor
• --dangerously-skip-permissions bayrağını kullanıyorsanız, buna benzer izole bir ortam kurmanız güçlü biçimde öneriliyor

[GN⁺]

Hacker News yorumları

• Claude'u kullanınca, birkaç ay sonra karar yorgunluğu (decision fatigue) yüzünden eninde sonunda Enter'a basıp geçiyorsun
  Bu yüzden benim hissim, YOLO modunda çalıştırıp bunun yerine bir sandbox ortamı kurmanın çok daha güvenli olduğu yönünde
  Ubuntu 22.04 üzerinde bubblewrap ve Landlock LSM'i birleştirerek katmanlı bir sandbox kurdum
  Landlock, dosya sistemi erişimini whitelist tabanlı olarak kısıtlıyor ve TCP port erişimini de kontrol ediyor
  bubblewrap, mount namespace'leri ayırarak proje bazlı /tmp oluşturuyor ve gizli anahtarları saklıyor
  dnsmasq ile DNS whitelist tanımlayıp yalnızca gerekli domain'lerin çözümlenmesine izin veriyorum
  Bu yapı sayesinde ajanı sürekli izlemek zorunda olmanın yarattığı stres azaldı

  • Ben de benzer bir ortamda birden fazla Claude instance'ını YOLO modunda çalıştırıyordum; Emacs TRAMP eklentisini yerel NUC üzerinde doğrudan derlemem gerektiğinde gerçekten yorucuydu
    Claude'un önerdiği elisp parçalarını tek tek onaylamak çok yıpratıcı bir deneyimdi
    Bash komutlarıyla alakasız bir şey kurmamasına dikkat etmek bile yorucuydu
  • Ben Windows kullanıyorum, o yüzden doğrudan denemedim; ama Linux'ta Claude Code içinde /sandbox komutuyla sandboxing özelliğinin yerleşik olduğunu sanıyordum

• Ben Docker'dan Srini
  Pek çok geliştirici bu sorunu çözmek için Docker kullanıyor ve Docker-in-Docker kısıtları hakkında da çok geri bildirim aldık
  Bu yüzden deneysel olarak Docker Sandboxes'ı önizleme şeklinde yayımladık
  Hâlâ erken aşamada, ama bir sonraki sürümü MicroVM tabanlı geliştiriyoruz ve Docker-in-Docker sorunundan kaçınmayı hedefliyoruz

  • Docker Sandbox'ın Docker-in-Docker sorununu nasıl çözdüğünü merak ediyorum
    Claude'un Docker Sandbox içinde başka container'ları yetki olmadan başlatıp başlatamayacağını bilmek istiyorum

• Görünüşe göre çoğu kişi yerelde doğrudan VM çalıştırmaktan kaçınıyor, nedenini anlayamıyorum
  Aslında yerel VM en basit seçenek ve tüm sorunları çözüyor
  Mac'te Docker kullanıyorsan zaten Linux VM üzerinde çalışıyorsun; yani gerçek ortama göre sadece bir katman fark var
  IDE'den SSH ile doğrudan bağlanıp kodu da inceleyebilirsin
  Ben --dangerously-skip-permissions seçeneğini açıyorum ve tüm değişiklikleri PR olarak yönetiyorum
  Bunu workmux ile birleştirip aylardır kullanıyorum; aynı anda birden fazla PR işleyebildiğim için çok verimli
  Cloud VM'lere göre daha iyi olmasının nedeni, aynı anda birden fazla container çalıştırınca belleğin çok hızlı tükenmesi
  Yüksek özellikli bir cloud VM'i 7/24 çalıştırmanın maliyeti çok yüksek

• Kötü niyetli bir yapay zeka, VM escape açığını kullanmasa bile Vagrantfile'a rastgele kod ekleyerek host erişimi elde edebilir
  Sadece basit hataları dert ediyor olsan bile, Claude commit hook'ları değiştirirse onlar çalıştığında sorun çıkar
  Tam izolasyonu korurken aynı zamanda rahat geliştirme yapmanın gerçekten zor olduğunu hissettiriyor

  • Claude'u belirli bir alt dizinle sınırlamak yeterli
    Örneğin Docker volume mount kullanarak sadece sandbox/ klasörünü değiştirebilir hâle getirip .git erişimini kapatabilirsin
  • Ama bu, VM ile host arasında dizinlerin çift yönlü paylaşılması varsayımını gerektiriyor
    Ben snapshot alıp küçük bir VM başlatıyor, ajanı çalıştırıyor ve sonra snapshot'ları karşılaştırıyorum
    Otomatik senkronizasyon izolasyon amacını bozduğu için bunu asla yapmıyorum
  • Bir başka risk de, kötü amaçlı kodun repoya eklenip daha sonra VM dışında çalıştırıldığında bulaşma yaratabilmesi
  • “ec2 düğümü?” diye kısa bir soru sorulmuş

• Ben farklı bir yaklaşım deniyorum — Claude'un çalıştırmak üzere olduğu şeyi yakalama yöntemi
  Shannot, çalıştırmadan önce niyeti yakalıyor ve PyPy sandbox içinde sistem çağrılarını araya girerek kontrol ediyor
  Komutlar ve dosya yazmaları sadece log'a düşüyor, gerçekten çalıştırılmıyor
  Kullanıcı TUI üzerinden inceleyip onaylarsa ancak o zaman yürütülüyor
  VM ile farkı şu: VM tamamen izole bir ortamda serbestçe çalıştırırken, Shannot gerçek sisteme insan onayı tabanlı değişiklikler uyguluyor
  Sunucu değişiklikleri gibi işler için uygun
  Claude MCP entegrasyonu, SSH ile uzaktan çalıştırma, checkpoint/rollback özellikleri de var

  • Bu yaklaşım sorunu doğrudan çözmüyor olabilir ama Claude Code'un yerleşik kontrol özellikleriyle benzer bir yönde gibi geliyor
    Sonuçta ilk onay isteğinde duruyor, yani ajan serbestçe keşif yapamıyor
    Benim istediğim, ajanın arada durmadan sonuna kadar denemesi ve sonra sonucun değerlendirilmesi
    Asıl zaman kazancı böyle oluyor
  • Leash ile benzer bir felsefesi var gibi görünüyor
    Leash'in mac-native system extension moduna benziyor ama tam etkileşimli onay modu henüz yok
    İlginç bir proje
  • “Komutlar ve dosya yazmaları sadece log'a düşüyor, gerçekten çalıştırılmıyor” kısmı aslında Claude'un zaten varsayılan olarak sunduğu bir özellik
  • İsmi gerçekten zekice

• Onay yorgunluğu birikince sonunda --dangerously-skip-permissions kullanmak istiyorsun
  Bu yüzden ben Claude Code'u bir devcontainer içinde çalıştırıyorum
  Dosya erişimi sadece repo ile sınırlı, ağ erişimi ise yalnızca whitelist'teki hedeflere açık
  Sonra bunu docker compose ile genelleştirdim; sıradaki adım Codex veya OpenCode gibi başka ajanlara destek eklemek
  Ağı host üzerindeki bir proxy üzerinden zorunlu yönlendirerek loglama ve kontrolü güçlendirmek istiyorum
  Şu anda bunu geçici olarak iptables ile yapıyorum
  Hâlâ erken aşamada ama oldukça iyi çalışıyor
  Kod: agent-sandbox

  • Ben de benzer bir kurulum deniyorum
    Ağ proxy'si olarak mitmproxy kullanıyorum; henüz mükemmel değil ama neredeyse oldu
  • Arkadaşlarla bir akşam içinde uygulamayı vibe coding ile yaptık ve Claude'a sunucu kümesinde root yetkisi verdik
    Claude saatler boyunca sistemi kendi başına kurup uygulamayı tamamladı
    Biz tek satır kod yazmadık ve sonuç şaşırtıcı derecede iyiydi
    Yapay zeka geliştirme hızının temposu gerçekten inanılmaz

• Benim çözümüm basit

  sandbox-run npx @anthropic-ai/claude-code
  

  Böylece npx komutu Bubblewrap sandbox içinde şeffaf şekilde çalışıyor ve yalnızca mevcut dizin görünür oluyor
  Saf POSIX shell ile birkaç satırda uygulanabiliyor
  sandbox-run

  • Bubblewrap yaklaşımını seviyorum ama sadece Linux'a özel olması üzücü
    Bir kez yetkileri bıraktıktan sonra geri alamamak da dezavantaj

• Ben sadece yetkisiz bir LXC container içine koyup geçiyorum
  Benim tehdit modelim karmaşık saldırılardan çok “yanlışlıkla home dizinini silmek” senaryosu

• Ben projenin run/ dizinine yardımcı script'ler koyup compose tabanlı container'lar başlatıyorum
  devcontainer, host diziniyle volume mapping üzerinden bağlı
  Servis yapılandırması, script güncellemeleri ve runtime sorunlarının teşhisini Claude gayet iyi hallediyor
  Tarayıcı entegrasyonu yok ama Playwright veya Puppeteer ile rahatlıkla yapılabilir gibi görünüyor

• Claude Code'un yerleşik sandboxing özelliği hakkında görüşleri merak ediyorum
  resmî doküman bağlantısı
  Claude Code'da gerektiğinde sandbox'ı kapatmayı sağlayan bir escape hatch var
  Bir komut sandbox kısıtları yüzünden başarısız olursa Claude nedeni analiz edip dangerouslyDisableSandbox ile yeniden deneyebiliyor
  Ajanın sandbox'ı kendi başına kapatabilmesi bir zafiyet gibi görünüyor; bu durumda kullanıcı onay süreci var mı merak ediyorum

  • Ne yazık ki bazen kullanıcı onay istemini atlama örnekleri oluyor
    İlgili issue'lar: #14268, #13583, #10089