Claude Code sunucuda güvenli nasıl çalıştırılır

Claude Code'ın bir sunucuda güvenli bir şekilde çalıştırılmasının anlamı

Claude Code'ı bir sunucuda güvenli bir şekilde çalıştırmak için; izin istemlerini açık tutun, uygulamayı özel bir yetkisiz kullanıcı (unprivileged user) olarak çalıştırın ve unattended (otomatik) çalıştırmalara güven yerine gerçek bir sınır verin: yerleşik sandbox, bir container veya içinde önemli bir veri barındırmayan geçici bir VPS. --dangerously-skip-permissions flag'i, model ile shell arasındaki onay adımını kaldırır. Bu takas, unattended işler için makul olabilir; ancak yalnızca tek bir hatalı komutun erişebileceği sınırların içinde. Bu kılavuz, flag'in gerçekte neleri değiştirdiğini ve bu sınırın artan izolasyon basamaklarıyla nasıl inşa edileceğini açıklar.

Claude Code makinenizde neler yapabilir

Claude Code, terminalinizde çalışan bir kodlama ajanıdır. Dosyaları okur, dosyalara yazar ve uygulamayı başlatan kullanıcı olarak shell komutlarını çalıştırır. Aracın tüm değeri budur: her komutu tek tek yazmanıza gerek kalmadan bir depoyu (repository) clone edebilir, kodu düzenleyebilir, testleri çalıştırabilir, hataları okuyabilir ve kodu bir döngü içinde düzeltebilir. Eğer henüz bir sunucuya kurmadıysanız, tmux ile bir VPS üzerinde Claude Code çalıştırmak kurulum ve oturum yönetimini kapsar. Bu sayfa, kurulum tamamlandıktan sonra ona devrettiğiniz yetkileri kapsar.

Risk, aynı cümlenin ikinci kez okunması gibidir. Shell komutlarını kullanıcınız olarak çalıştıran bir süreç, kullanıcınızın yapabildiği her şeyi yapabilir. Kullanıcınızın açabildiği ~/.ssh/id_ed25519, ~/.aws/credentials ve her bir .env dosyasını okuyabilir. curl çalıştırabilir ve sunucunun erişebildiği herhangi bir host'a veri gönderebilir. git push --force çalıştırabilir. Ajanın kendi motivasyonu yoktur. Tehlike, bir görevin yanlış gitmesi veya çalışma sırasında okuduğu metnin başka biri tarafından yazılmış talimatlar içermesidir: çektiği bir web sayfası veya düzeltmesi istenen bir issue içindeki bir yorum. İkinci duruma prompt injection denir ve "model genellikle mantıklıdır" ifadesinin neden bir güvenlik planı olmadığını açıklar. Hatalı bir çalışma için değil, ortalama bir çalışma için plan yapın.

İzin sisteminin basit anlatımı

Claude Code, varsayılan olarak bir eylemden önce onay ister. Proje içindeki dosyaları okuma işlemi sessizce gerçekleşir, ancak bir dosyayı düzenlemek veya bir shell komutu çalıştırmak, önce size tam düzenlemeyi veya komutu gösterir ve bir onay bekler. Tek bir eylemi onaylayabilir veya oturumun geri kalanı için bu tür eylemleri onaylayabilirsiniz. Bu onaylar oturum kapsamlıdır: CLI'dan çıkarsanız, bir sonraki oturum tekrar temkinli başlar. Kalıcı olmasını istediğiniz kurallar için ayarlar dosyası kalıcı allow, ask ve deny listelerini tutar. Örneğin: git status için allow, git push için ask, .env okumaları için deny. Deny kuralları her zaman üstündür.

Bu tasarım, bir insanın terminalı izlediğini varsayar ve bir laptop üzerinde bu doğrudur. Bir sunucuda ise nokta genellikle kimsenin izlemiyor olmasıdır. tmux içinde uzun bir görev başlatıp uyuyabilirsiniz ve saat gece 02:00'de soru sormak için duran bir ajan, sabah olana kadar ilerleme kaydedemez. Duraklama, zaman kadar maliyet de yaratır; çünkü boşta kalan bir Claude Code oturumu sıcak prompt cache'ini kaybeder ve bir sonraki tur bunu yeniden oluşturmak için ödeme gerektirir. İnsanların sunucularda skip flag'ine başvurmasının dürüst nedeni budur ve çözdüğü sorun gerçektir. Bu kılavuzun geri kalanı, tüm koruma mekanizmalarından vazgeçmeden bu sorunu çözmek hakkındadır.

--dangerously-skip-permissions neyi değiştirir

claude --dangerously-skip-permissions onay adımını kapatır. Düzenlemeler bir istem olmadan gerçekleşir. Shell komutları bir istem olmadan çalışır. Normalde hassas konumları koruyan protected-path kontrolleri de atlanır. Açıkça belirttiğiniz deny kuralları hala geçerlidir ve birkaç ekstrem eylem hala durup sormaya devam eder, ancak çalışma özeti basittir: modelin çalıştırmaya karar verdiği her şey çalışır.

Bir sunucuda bu flag ile ilgili iki gerçek önemlidir. Birincisi, Claude Code Linux ve macOS üzerinde root veya sudo ile çalışırken engellenir; çünkü istemleri olmayan bir root, makinedeki herhangi bir dosyayı veya servisi değiştirebilir. Ajanın zaten kendi yetkisiz hesabına ihtiyacı vardır ve flag bunu zorunlu kılar. İkincisi, flag modelin davranışını hiçbir şekilde değiştirmez. Döngüden insanı çıkarır ve başka hiçbir şeyi değiştirmez, bu nedenle bir istemin yakalayabileceği her hata artık yürütülür.

İşte dürüst hesaplama şudur: Eğer izinleri atlarsanız, güvenlik sorusu "ajan kötü bir şey yapacak mı"dan "tek bir hatalı eylem ne kadar hasar verebilir"e dönüşür. Her kararı kontrol etmeye çalışmayı bırakıp patlama yarıçapını (blast radius) kontrol etmeye başlarsınız. Çözüm containment (sınırlama) yöntemidir ve bu yöntem basamaklar halinde gelir.

Yerleşik Claude Code sandbox'ı

Basamaklardan önce, Claude Code'un artık çalıştırdığı komutlar için işletim sistemi düzeyinde bir sandbox ile birlikte geldiğini ve insanların skip flag'ine başvurma nedenlerinin çoğunu ortadan kaldırdığını bilin. Linux'ta dosya sistemi izolasyonu için bubblewrap, ağ trafiğini bir proxy üzerinden yönlendirmek için ise socat kullanır. Sandbox içinde bir komut yalnızca proje dizinine ve bir oturum geçici dizinine yazabilir ve ağa yalnızca her domain'i bir allow listesine göre kontrol eden bir proxy aracılığıyla erişebilir. Bir komut yeni bir domain istediğinde, Claude Code size sorar.

Bir oturum içinde /sandbox komutu ile aktif hale getirin. Ubuntu ve Debian'da, önce ihtiyaç duyduğu iki paketi kurun:

sudo apt install bubblewrap socat

Ubuntu 24.04 ve sonrası için, varsayılan AppArmor politikası bubblewrap'in ihtiyaç duyduğu user namespace'leri oluşturmasını engeller. Sandbox paneli bir şey eksik olduğunda size bildirir ve Claude Code sandboxing dokümantasyonu bunu düzelten kısa AppArmor profilini içerir.

Sandbox'ın bir auto-allow modu vardır: sandboxed komutlar herhangi bir istem olmadan çalışır, çünkü zorunlu kılınan sınır artık istemin yaptığı işi yapmaktadır. Sandbox içinde çalışamayan komutlar normal izin akışına geri döner, böylece gerçekten olağandışı eylemler hala sorar. Çoğu sunucu iş akışı için bu, skip flag için doğru alternatiftir; çünkü hiçbir şey olmaması yerine, işletim sistemi tarafından zorunlu kılınan bir sınır ile çok daha az soru alırsınız.

Sınırları konusunda dürüst olun. Varsayılan olarak, siz bu yolları yasaklamadığınız sürece, sandboxed bir komut kimlik dosyaları dahil olmak üzere dosya sisteminin çoğunu hala okuyabilir; sandbox.credentials ayarı tam olarak bunun içindir. Ağ proxy'si domain adlarını kontrol eder ve trafiğin kendisini incelemez, bu nedenle github.com gibi geniş bir allow, verileri dışarı çıkarmak için hala alan bırakır. Docker içinde çalışmaz. Sandbox tabanı oldukça yükseltir. Tam bir izolasyon sınırı değildir, bu nedenle aşağıdaki basamaklar hala önemlidir.

Containment ladder (Sınırlama merdiveni)

Artan izolasyon sırasıyla üç basamak. Makinede başka neler yaşadığına uyan en düşük basamağı seçin.

Basamak 1: özel bir yetkisiz kullanıcı. Ajanın kendi hesabı, kendi home dizini, kendi proje dizini olur ve sudo yetkisi yoktur:

sudo adduser --disabled-password --gecos "" agent

Hesap sınırı, ajanı dosyalarınızdan uzak tutar: SSH anahtarlarınız ve makinedeki diğer tüm projeleriniz. Ayrıca, flag root olarak çalışmayı reddettiği için skip flag'in kullanılabilir olmasını sağlar. Bu, bir ajana uygulanan her servisin yetkisiz bir kullanıcı olarak çalıştırılması ilkesiyle aynıdır. Basamak 1'in sınırlandırmadığı şeyler: ağ ve makinedeki dünya tarafından okunabilir (world-readable) olan her şeydir.

Basamak 2: bir container. Anthropic, Claude Code'u root olmayan bir kullanıcı olarak çalıştıran ve ajanın hangi hostlara erişebileceğini sınırlayan firewall kurallarına sahip referans bir devcontainer yayınlar; sizin oluşturduğunuz bir container da aynı işi yapar. Dosya sistemi bağladığınız (mount) volumeler ile sınırlanır ve egress, container kurallarının izin verdiği kadar daralır. Sunucu sizin için önemli olan başka servisleri barındırıyorsa doğru orta basamak budur. Sınırı, container'ların host kernel'ini paylaşmasıdır ve tek bir dikkatsiz mount sınırı bozar; container'a /var/run/docker.sock verirseniz tüm host'a erişebilir.

Basamak 3: özel bir VPS. En güçlü basamak en kaba olanıdır: ajana içinde sizin için önemli olan hiçbir şey bulunmayan tamamen ayrı bir makine verin. Küçük bir VPS ayda birkaç dolara mal olur. Onu yeni bir VPS üzerindeki ilk on dakika runbook ile kurun, temiz durumu snapshot olarak alın ve ajanın çalışmasına izin verin. Orada başka hiçbir şey yaşamaz. Kişisel SSH anahtarı yok, sadece ilgili tek bir repository için sınırlandırılmış bir deploy key var. Bulut kimlik bilgileri yok, üretim verisi yok. Bir çalışma ters giderse veya sadece temiz bir sayfa isterseniz, snapshot'ı geri yükleyin veya makineyi dakikalar içinde yok edip yeniden kurun. Patlama yarıçapı kiradır. --dangerously-skip-permissions'un korkutucu olmaktan çıktığı kurulum budur, çünkü en kötü gerçekçi sonuç yeniden kurulan bir sunucu ve iptal edilen tek bir tokendir.

Basamaklar üst üste biner. Yetkisiz bir kullanıcı olarak çalışan, geçici bir VPS üzerindeki sandboxed bir ajan, neredeyse hiçbir ek maliyet getirmez ve hata hikayelerini sıkıcı hale getirir. Hedef sıkıcı olmaktır.

Kimlik bilgilerini koruyun

Diğer her şeyin maliyetini karşılayan kural: ajanın kullanıcısı, başka hiçbir şeye ait olan sırları (secrets) okuyabilmemelidir.

API anahtarını yalnızca ajana verin, başka hiçbir yere değil. Onu ajanın kullanıcısına ait 600 modunda bir dosyaya koyun ve bir shell başladığında yükleyin:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

Ardından diğer yönü kapatın. Debian ve Ubuntu'da home dizinleri genellikle makinedeki her kullanıcı tarafından okunabilir olarak oluşturulur, bu yüzden sizinkini sıkılaştırın: chmod 750 /home/youruser. ls -ld /home/* ile kontrol edin ve ajanın hesabının listeleyebildiği her şeyi düzeltin.

Her token'ı sınırlandırın. Tek bir repository ile sınırlı hassas bir GitHub token'ı veya repository başına bir deploy key, bir kimlik bilgisi sızdığında tüm hesabınızın değil, sadece bir projenizin kaybedilmesi anlamına gelir. Eğer sandbox kullanıyorsanız, ~/.ssh ve ~/.aws'un okuma işlemleri için bile reddedilmesi için kimlik bilgisi ayarlarını ekleyin. Ve üretim kimlik bilgilerini makinede tamamen tutmayın, çünkü bir ajan hiç var olmamış bir sırrı sızdıramaz.

Git bir güvenlik ağıdır

Ajanın yaptığı her değişiklik incelenebilir ve geri alınabilir olmalıdır; ajan bir branch üzerinde çalışıyorsa git size her ikisini de ücretsiz olarak sunar:

git switch -c agent/refactor-auth

Çalışmayı git diff main...agent/refactor-auth ile sonradan inceleyin, iyi olanı merge edin ve çalışma bir yere varmadıysa branch'i silin. Forge tarafında main branch'i koruyun, böylece ajanın token'ı oraya push yapamaz ve hiçbir yere force-push yapamaz. Commit geçmişi, siz uyurken neler olduğuna dair bir denetim günlüğü (audit log) görevi görür ki bu, herhangi bir terminal scrollback miktarından daha değerlidir.

Ağ, patlama yarıçapının bir parçasıdır

Bir ajan curl çalıştırabilir. Bu cümle tüm egress (çıkış) problemini özetler: ajanın okuyabildiği her şeyi bir yere gönderebilir ve prompt injection yapılmış bir ajan bunu yapabilir. Düz bir yetkisiz kullanıcı bunu hiçbir şekilde sınırlandırmaz, çünkü herhangi bir kullanıcı sunucunun erişebildiği her yere erişebilir. Sandbox, proxy aracılığıyla domain bazında bunu sınırlandırır. Bir container, kendi firewall kurallarıyla bunu sınırlandırabilir. Özel bir VPS, en başta sızdırılacak olan şeylerin miktarını sınırlandırır ki bu üçü arasındaki en sağlam cevaptır.

Egress sorununu sadece ufw ile çözmeye çalışmayın. ufw varsayılan olarak tüm giden trafiğe izin verir ve apt, npm, git ve Claude API'ye hala izin veren çıkış kuralları yazmak, sessizce bozulan zahmetli bir iştir. Bunun yerine, bir domain allow listesi veya çıplak bir makinenin aynı işi temiz bir şekilde yaptığı sandbox, container veya makine seviyesinde sınırı seçin.

Claude Code çalıştırmak yerine API'ye karşı kendi ajanınızı oluşturuyorsanız, aynı düşünce yapısı değişmeden geçerlidir. VPS üzerinde Claude ile bir AI ajanı oluşturmak bu yolu kapsar ve ajanı da aynı özel kullanıcıyı, aynı sınırlandırılmış token'ları ve aynı geçici kutuyu hak eder.

Önce makineyi sertleştirin (Harden)

Hangi basamağı seçerseniz seçin, ajan yerleşmeden önce makinenin kendisinin temel gereksinimlere ihtiyacı vardır: sadece SSH anahtarları, root girişi yok, varsayılan olarak reddeden (default-deny) bir firewall, otomatik güvenlik güncellemeleri. Kontrol listenizi burada oluşturun ve bir kez uygulayın:

FAQ

--dangerously-skip-permissions bir sunucuda kullanmak için güvenli mi?

Tek başına değil. Flag her onay istemini kaldırır, bu nedenle ilk hatalı komut model onu ürettiği anda çalışır. Patlama yarıçapı sınırlandırıldığında bu kabul edilebilir bir takas haline gelir: en azından özel bir yetkisiz kullanıcı ve gerçekten unattended işler için tek bir proje ve tek bir sınırlandırılmış token barındıran bir container veya geçici bir VPS. Üretim kimlik bilgilerini veya kaybedemeyeceğiniz verileri barındıran bir makinede asla kullanmayın.

Claude Code'un bir sandbox'ı var mı?

Evet. Claude Code, /sandbox komutuyla açılan, shell komutları için yerleşik bir sandbox ile birlikte gelir. Linux'ta bubblewrap ve macOS'ta Seatbelt kullanır, yazma işlemlerini proje dizini ile sınırlandırır ve ağ erişimini yalnızca onaylanmış domainlere izin veren bir proxy üzerinden yönlendirir. Auto-allow modu, sandboxed komutları istemler olmadan çalıştırır, böylece skip flag gibi kesintileri azaltırken işletim sistemi tarafından zorunlu kılınan bir sınır korur. Tam bir izolasyon sınırı değildir, bu nedenle unattended çalıştırmalar için onu özel bir kullanıcı veya özel bir makine ile eşleştirin.

Skip flag neden root olarak çalışmayı reddediyor?

Çünkü istemleri olmayan bir root, sistemdeki herhangi bir dosyayı ve servisi değiştirebilir; Claude Code, Linux ve macOS üzerinde root veya sudo ile çalışırken --dangerously-skip-permissions işlemini engeller. Çözüm, kontrolle savaşmak değildir. Ajan için yetkisiz bir kullanıcı oluşturun ve orada çalıştırın; bu hesap sınırı, containment'ın ilk ve en ucuz katmanıdır.

Claude Code SSH anahtarlarımı ve .env dosyalarımı okuyabilir mi?

Çalıştığı kullanıcının okuyabildiği her şeyi okuyabilir ve hatta sandbox'ın varsayılan politikası, siz yasaklayana kadar kimlik bilgisi yollarının okunmasına izin verir. Bu yüzden ajanı kendi kullanıcısı olarak çalıştırın, kendi home dizininizi 750 veya daha sıkı modda tutun, sandbox ayarlarında kimlik bilgisi yollarını yasaklayın ve üretim sırlarını makineden tamamen uzak tutun. Makinenin hiç barındırmadığı bir sır okunamayabilir veya sızdırılamaz.

Claude Code'u unattended çalıştırmanın en güvenli yolu nedir?

Yalnızca ajan işleri için kullanılan ucuz, özel bir VPS: on dakikada sertleştirilmiş, temiz bir şekilde snapshot alınmış, sandbox açık bir şekilde yetkisiz bir kullanıcı altında Claude Code çalıştıran, 600 modunda bir dosya içinde API anahtarı tutan, repository başına bir deploy key olan ve tüm çalışmaların merge edilmeden önce incelediğiniz branch'lerde olduğu bir kurulum. Bir çalışma ters giderse, bir token'ı iptal edersiniz ve snapshot'ı geri yüklersiniz; sahip olduğunuz başka hiçbir şey etkilenmez.