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

Claude Code uygulamasını bir sunucuda güvenli şekilde çalıştırmanın anlamı

Claude Code uygulamasını bir sunucuda güvenli şekilde çalıştırmak için izin istemlerini açık tutun, uygulamayı yetkisiz bir kullanıcı hesabıyla çalıştırın ve gözetimsiz işlemler için güvene dayalı bir yapı yerine gerçek sınırlar oluşturun: yerleşik sandbox, bir container veya içinde önemli veri barındırmayan geçici bir VPS kullanın. --dangerously-skip-permissions bayrağı, model ile shell arasındaki onay adımını kaldırır. Bu takas, gözetimsiz işlemler için makul olabilir ancak yalnızca hatalı bir komutun erişebileceği alanı sınırlayan bir sınır içerisinde yapılmalıdır. Bu kılavuz, söz konusu bayrağın gerçekte neleri değiştirdiğini ve bu sınırı artan izolasyon kademeleriyle nasıl oluşturacağınızı açıklar.

Claude Code sisteminizde neler yapabilir

Claude Code, terminalinizde çalışan bir kodlama ajanıdır. Dosyaları okur, dosyaları yazar ve başlatıldığı kullanıcının yetkileriyle shell komutlarını çalıştırır. Aracın tüm değeri buradan gelir: Bir repoyu klonlayabilir, kodu düzenleyebilir, testleri çalıştırabilir, hata çıktılarını okuyabilir ve her komutu sizin yazmanıza gerek kalmadan kodu bir döngü içerisinde düzeltebilir. Eğer henüz bir sunucu üzerinde kurulum yapmadıysanız, tmux ile VPS üzerinde Claude Code çalıştırma rehberi kurulumu ve oturum yönetimini kapsamaktadır. Bu sayfa, aracı kurduktan sonra ona verdiğiniz yetkileri ele almaktadır.

Risk, aynı cümlenin ikinci kez okunmasıyla aynıdır. Kullanıcınızın yetkileriyle shell komutlarını çalıştıran bir süreç, kullanıcınızın yapabileceği her şeyi yapabilir. ~/.ssh/id_ed25519, ~/.aws/credentials ve kullanıcınızın açabildiği her .env dosyasını okuyabilir. curl komutunu çalıştırabilir ve sunucunun erişebildiği herhangi bir ana bilgisayara veri gönderebilir. git push --force komutunu çalıştırabilir. Ajanın kendi başına bir motivasyonu yoktur. Tehlike, bir görevin yanlış gitmesi veya çalışırken okuduğu metinlerin başka biri tarafından yazılmış talimatlar içermesidir: getirdiği bir web sayfası veya düzeltmesi istenen bir issue içindeki yorum gibi. Bu ikinci duruma prompt injection denir ve "model genellikle mantıklıdır" düşüncesinin bir güvenlik planı olmamasının nedeni budur. Talimatlar daha yakın kaynaklardan da gelebilir; çünkü aynı sunucudaki iki Claude Code oturumu birbirine metin gönderebilir ve kardeş bir oturumdan gelen mesaj, alıcı ajanın okuduğu metinden ibarettir. Planlamanızı ortalama bir senaryoya göre değil, kötü giden bir senaryoya göre yapmalısınız.

İzin sistemi basit bir dille

Claude Code, varsayılan olarak herhangi bir işlem yapmadan önce onay ister. Proje içindeki dosyaların okunması sessizce gerçekleşir; ancak bir dosyayı düzenlemek veya bir shell komutu çalıştırmak istediğinde, tam olarak yapılacak değişikliği veya komutu size gösterir ve onayınızı bekler. Tek bir işlemi onaylayabilir veya o oturumun geri kalanı için bu tür işlemlere izin verebilirsiniz. Bu onaylar oturum bazlıdır: CLI'dan çıktığınızda, bir sonraki oturum tekrar temkinli başlar. Kalıcı olmasını istediğiniz kurallar için ayar dosyası; izin verilen (allow), sorulan (ask) ve reddedilen (deny) listelerini tutar. Örneğin: git status için izin ver, git push üzerinde sor, .env dosyalarının okunmasını reddet. Reddetme kuralları her zaman önceliklidir. 14 August 2026 tarihinde otomatik mod varsayılan hale geleceği için bu temel yapı değişmektedir; bu nedenle, başında duramayacağınız bir sunucuda hangi modun çalışacağına karar vermeden önce her bir izin modunun gerçekte nelere izin verdiğini bilmenizde fayda vardır.

Bu tasarım, terminali izleyen bir insan olduğu varsayımıyla oluşturulmuştur; bir dizüstü bilgisayarda bu durum geçerlidir. Sunucuda ise genellikle kimse izlemez. Uzun süren bir görevi tmux içinde başlatıp uyumaya gidersiniz; saat 02:00'de soru sormak için duran bir aracı, sabaha kadar hiçbir ilerleme kaydedemez. Bu duraklama hem zaman hem de para kaybına neden olur, çünkü boşta kalan bir Claude Code oturumu sıcak istem önbelleğini (prompt cache) kaybeder ve bir sonraki adımda bu önbelleği yeniden oluşturmak için maliyet ödenir. İnsanların sunucularda skip bayrağına başvurmalarının dürüst nedeni budur ve çözdüğü sorun gerçektir. Bu kılavuzun geri kalanı, tüm güvenlik önlemlerinden vazgeçmeden bu sorunu nasıl çözeceğiniz hakkındadır.

--dangerously-skip-permissions bayrağının etkileri

claude --dangerously-skip-permissions onay adımını devre dışı bırakır. Düzenlemeler herhangi bir uyarı olmaksızın gerçekleşir. Kabuk komutları onay istenmeden çalıştırılır. Hassas konumları koruyan korumalı yol denetimleri de atlanır. Açıkça belirttiğiniz reddetme kuralları geçerliliğini korur ve bazı uç eylemler hala onay gerektirebilir; ancak çalışma mantığı basittir: model neyi çalıştırmaya karar verirse, o çalışır.

Bir sunucuda bu bayrakla ilgili iki önemli gerçek vardır. Birincisi, Claude Code Linux ve macOS üzerinde root olarak veya sudo ile çalıştırıldığında bu bayrak engellenir; çünkü root yetkisiyle onay mekanizması olmadan çalışmak, makinedeki herhangi bir dosyayı veya servisi değiştirebilir. Aracın zaten kendi ayrıcalıksız hesabına sahip olması gerekir ve bu bayrak bunu zorunlu kılar. İkincisi, bayrak modelin davranışını hiçbir şekilde değiştirmez. Sadece insanı döngüden çıkarır, başka hiçbir şeyi değiştirmez; bu nedenle bir uyarı ile engellenebilecek her hata artık doğrudan yürütülür.

İşin özü şudur: İzinleri atladığınızda, güvenlik sorusu "aracı kötü bir şey yapacak mı" sorusundan "tek bir hatalı eylem ne kadar hasar verebilir" sorusuna dönüşür. Her kararı kontrol etmeye çalışmayı bırakıp etki alanını (blast radius) kontrol etmeye başlarsınız. Çözüm sınırlamadır ve bu da kademeli olarak uygulanır.

Dahili Claude Code sandbox yapısı

Komutları çalıştırmadan önce bilinmelidir ki Claude Code artık çalıştırdığı komutlar için işletim sistemi seviyesinde bir sandbox sunmaktadır ve bu durum, kullanıcıların --skip bayrağına başvurma nedenlerinin çoğunu ortadan kaldırmaktadır. Linux üzerinde dosya sistemi izolasyonu için bubblewrap, ağ trafiğini bir proxy üzerinden yönlendirmek için ise socat kullanır. Sandbox içerisinde bir komut yalnızca proje dizinine ve oturuma özel geçici bir dizine yazabilir; ağa ise yalnızca her alan adını bir izin listesine göre kontrol eden bir proxy üzerinden erişebilir. Bir komut ilk kez yeni bir alan adına erişmek istediğinde, Claude Code size onay sorar.

Bu özelliği bir oturum içerisinde /sandbox komutu ile aktif edebilirsiniz. Ubuntu ve Debian üzerinde, öncelikle ihtiyaç duyduğu iki paketi kurun:

sudo apt install bubblewrap socat

Ubuntu 24.04 ve sonraki sürümlerde, varsayılan AppArmor politikası bubblewrap'in ihtiyaç duyduğu kullanıcı isim alanlarını (user namespaces) oluşturmasını engeller. Sandbox paneli bir eksiklik olduğunda sizi uyarır ve Claude Code sandbox dokümantasyonu, bu sorunu çözen kısa AppArmor profilini içerir.

Sandbox'ın otomatik izin modu bulunur: Sandbox içerisindeki komutlar herhangi bir onay istemeden çalışır, çünkü uygulanan sınırlar daha önce onay isteminin yaptığı işi üstlenir. Sandbox içerisinde çalışamayan komutlar normal izin akışına geri döner, bu nedenle gerçekten sıra dışı eylemler için yine onay istenir. Çoğu sunucu iş akışı için bu, --skip bayrağının doğru alternatifidir; çünkü hiçbir kısıtlama olmaması yerine işletim sistemi tarafından zorlanan bir sınır ile çok daha az soruyla karşılaşırsınız.

Sınırları konusunda dürüst olun. Varsayılan olarak bir sandbox komutu, bu yolları reddetmediğiniz sürece kimlik bilgisi dosyaları dahil olmak üzere dosya sisteminin büyük bir kısmını okuyabilir; sandbox.credentials ayarı tam olarak bunun içindir. Ağ proxy'si alan adlarını kontrol eder ancak trafiğin içeriğini denetlemez; bu nedenle github.com gibi geniş bir izin, verilerin dışarı çıkarılmasına olanak tanır. Docker bu yapı içerisinde çalışmaz. Sandbox güvenlik seviyesini önemli ölçüde yükseltir. Tam bir izolasyon sınırı değildir, bu yüzden aşağıdaki basamaklar hala önemini korumaktadır.

Kapsülleme basamakları

Artan izolasyon seviyesine göre üç basamak. Sunucuda başka nelerin barındığına bağlı olarak en düşük seviyeyi seçin.

1. Basamak: özel ve yetkisiz bir kullanıcı. Ajan kendi hesabına, kendi ana dizinine, kendi proje dizinine sahip olur ve sudo yetkisi bulunmaz:

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

Hesap sınırı, ajanı sizin dosyalarınızdan; yani SSH anahtarlarınızdan ve makinedeki diğer tüm projelerden uzak tutar. Ayrıca, root olarak çalışmayı reddettiği için skip bayrağının kullanılabilir olmasını sağlar. Bu, her servisi yetkisiz bir kullanıcı olarak çalıştırma prensibinin bir ajana uygulanmış halidir. 1. basamağın sınırlayamadığı şeyler: ağ erişimi ve makinede herkes tarafından okunabilir olan dosyalardır.

2. Basamak: bir container. Anthropic, Claude Code'u root olmayan bir kullanıcı olarak çalıştıran ve ajanın hangi ana makinelere erişebileceğini sınırlayan güvenlik duvarı kurallarına sahip bir referans devcontainer yayınlamaktadır; kendi oluşturduğunuz bir container da aynı işi görür. Dosya sistemi, bağladığınız (mount) birimlerle sınırlanır ve dışa giden trafik, container kurallarının izin verdiği ölçüde kısıtlanır. Sunucuda önemsediğiniz başka servisler barındırıyorsanız bu, doğru orta basamaktır. Sınırı, container'ların ana makine çekirdeğini paylaşmasıdır; dikkatsizce yapılan bir mount işlemi sınırı geçersiz kılar; container'a /var/run/docker.sock yetkisi verirseniz tüm ana makineye erişebilir.

3. Basamak: özel bir VPS. En güçlü basamak en basit olanıdır: ajana, önemsediğiniz hiçbir şeyi barındırmayan tamamen ayrı bir makine verin. Küçük bir VPS ayda birkaç dolara mal olur. Makineyi yeni bir VPS için ilk on dakika rehberi ile kurun, temiz durumun anlık görüntüsünü (snapshot) alın ve ajanın çalışmasına izin verin. Orada başka hiçbir şey barınmasın. Kişisel SSH anahtarı olmasın, yalnızca tek bir depoya (repository) tanımlanmış bir deploy anahtarı olsun. Bulut kimlik bilgileri veya üretim verisi olmasın. Bir işlem hatalı gittiğinde veya sadece temiz bir başlangıç istediğinizde, anlık görüntüyü geri yükleyin ya da makineyi dakikalar içinde yok edip yeniden oluşturun. Patlama yarıçapı, ödediğiniz kira kadardır. Bu kurulumda --dangerously-skip-permissions korkutucu olmaktan çıkar, çünkü gerçekleşebilecek en kötü gerçekçi sonuç, yeniden oluşturulan bir sunucu ve iptal edilen tek bir belirteçtir (token) olur.

Basamaklar birbiri üzerine eklenebilir. Yetkisiz bir kullanıcı olarak, atılabilir bir VPS üzerinde çalışan korumalı (sandboxed) bir ajanın maliyeti neredeyse sıfırdır ve olası hata senaryolarını önemsiz hale getirir. Hedef, sıkıcı olmaktır.

Kimlik bilgilerini koruyun

Diğer tüm güvenlik önlemlerinin temelini oluşturan kural şudur: Aracın (agent) kullanıcısı, kendisine ait olmayan hiçbir gizli veriyi okuyamamalıdır.

API anahtarını yalnızca araca verin, başka hiçbir yere vermeyin. Anahtarı, sahibi aracın kullanıcısı olan ve 600 izin moduna sahip bir dosyaya yerleştirin ve bir shell başladığında yüklenmesini sağlayın:

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 üzerinde ev dizinleri genellikle sunucudaki tüm kullanıcılar tarafından okunabilir şekilde oluşturulur, bu yüzden kendi dizininizi kısıtlayın: chmod 750 /home/youruser. ls -ld /home/* ile kontrol edin ve aracın hesabının listeleyebildiği her şeyi düzeltin.

Her token için kapsam belirleyin. Tek bir repository ile sınırlandırılmış ayrıntılı bir GitHub token veya repository bazlı bir deploy key kullanmak, bir kimlik bilgisi sızdırıldığında tüm hesabınızın değil, yalnızca ilgili projenin tehlikeye girmesi anlamına gelir. Sandbox kullanıyorsanız, kimlik bilgisi ayarlarını ekleyerek ~/.ssh ve ~/.aws komutlarının okuma işlemleri için bile reddedilmesini sağlayın. Üretim ortamına ait kimlik bilgilerini ise sunucuda kesinlikle bulundurmayın; çünkü araç, sunucuda hiç var olmayan bir gizli veriyi sızdıramaz. Eğer bu gizli veriler self-hosted bir parola yöneticisinde tutuluyorsa, yöneticiyi araçtan farklı bir sunucuda barındırın ve ayrı bir denetimden geçirin; çünkü Vaultwarden'ın zayıf noktaları, şifreli kasanın kendisinden ziyade yönetici token'ı ve yedekleme dosyasıdır.

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ıştığı takdirde git her ikisini de ücretsiz olarak sağlar:

git switch -c agent/refactor-auth

Çalıştırma sonucunu git diff main...agent/refactor-auth ile inceleyin, iyi olanları merge edin ve çalıştırma bir sonuç vermediyse branch'i silin. Üç dosyaya dokunan bir çalıştırmayı incelemek, modülün yarısını yeniden yazan bir çalıştırmayı incelemekten çok daha kolaydır; bu durum ajani çalışan en küçük değişikliğe zorlayan bir beceri için pratik bir örnektir. Forge tarafında main branch'i korumaya alın; böylece ajanın token'ı bu branch'e push yapamaz ve hiçbir yere force-push gerçekleştiremez. Commit geçmişi, siz uyurken neler olduğuna dair bir denetim günlüğü (audit log) işlevi görür ve bu, terminaldeki herhangi bir kaydırma geçmişinden çok daha değerlidir.

Ağ, etki alanının bir parçasıdır

Bir ajan curl çalıştırabilir. Bu cümle, tüm çıkış trafiği (egress) problemini özetler: Ajanın okuyabildiği her şey, başka bir yere gönderilebilir; prompt injection saldırısına uğramış bir ajan bunu yapabilir. Yetkisiz bir kullanıcı bu durumu hiçbir şekilde sınırlamaz, çünkü herhangi bir kullanıcı sunucunun erişebildiği her yere ulaşabilir. Sandbox, bunu proxy aracılığıyla alan bazında sınırlar. Bir container, kendi güvenlik duvarı kurallarıyla bunu kısıtlayabilir. Özel bir VPS ise, sızdırılabilecek veriyi en başta sınırlandırarak bu üç yöntem arasındaki en sağlam çözümü sunar.

Çıkış trafiği sorununu yalnızca ufw ile çözmeye çalışmayın. ufw varsayılan olarak tüm giden trafiğe izin verir; apt, npm, git ve Claude API trafiğine izin verirken diğerlerini kısıtlayan kurallar yazmak zahmetlidir ve sessizce bozulabilir. Bunun yerine sınırı sandbox, container veya makine seviyesinde belirleyin; izin verilen alan adları listesi veya izole bir makine aynı işi daha temiz bir şekilde yapar.

Eğer Claude Code çalıştırmak yerine API üzerinde kendi ajansınızı geliştiriyorsanız, aynı mantık geçerlidir. VPS üzerinde Claude ile yapay zeka ajanı oluşturma bu yolu kapsar; söz konusu ajan da aynı şekilde özel bir kullanıcıyı, kapsamı sınırlandırılmış token'ları ve tek kullanımlık bir ortamı hak eder.

Sunucuyu öncelikle sıkılaştırın

Hangi yöntemi seçerseniz seçin, aracı (agent) yüklemeden önce makinenin temel güvenlik gereksinimlerini karşılaması gerekir: yalnızca SSH anahtarlarıyla erişim, root girişi yasağı, varsayılan olarak reddeden (default-deny) bir güvenlik duvarı ve otomatik güvenlik güncellemeleri. Kontrol listenizi burada oluşturun ve sırayla uygulayın:

FAQ

--dangerously-skip-permissions bayrağını sunucuda kullanmak güvenli midir?

Tek başına değildir. Bu bayrak tüm onay istemlerini devre dışı bırakır, bu nedenle model hatalı bir komut ürettiği anda bu komut çalıştırılır. Etki alanı sınırlandırıldığında (en azından yetkisiz bir kullanıcı hesabı kullanıldığında) bu yöntem savunulabilir bir tercihe dönüşür. Gerçekten gözetimsiz işlemler için ise tek bir projeyi ve sınırlı kapsamlı bir token'ı barındıran bir container veya tek kullanımlık bir VPS tercih edilmelidir. Üretim ortamına ait kimlik bilgilerini veya kaybetmeyi göze alamayacağınız verileri barındıran bir makinede bu bayrağı asla kullanmayın.

Claude Code bir sandbox içeriyor mu?

Evet. Claude Code, /sandbox komutu ile açılan, kabuk komutları için yerleşik bir sandbox ile gelir. Linux üzerinde bubblewrap, macOS üzerinde ise Seatbelt kullanır; yazma işlemlerini proje dizini ile sınırlar ve ağ erişimini yalnızca onaylı alan adlarına izin veren bir proxy üzerinden yönlendirir. Otomatik izin modu, sandbox içindeki komutları istem sormadan çalıştırır; böylece işletim sistemi düzeyinde bir sınır korurken, bayrak kullanımındaki gibi kesintileri azaltır. Bu tam bir yalıtım sınırı değildir; bu nedenle gözetimsiz çalıştırmalar için özel bir kullanıcı veya özel bir makine ile birlikte kullanın.

Skip bayrağı neden root olarak çalışmayı reddediyor?

İzin istemleri olmayan bir root kullanıcısı, sistemdeki her dosyayı ve her servisi değiştirebileceği için Claude Code, Linux ve macOS üzerinde root veya sudo yetkileriyle çalıştırıldığında --dangerously-skip-permissions kullanımını engeller. Çözüm, bu denetimi aşmaya çalışmak değildir. Ajan için yetkisiz bir kullanıcı oluşturun ve onu bu kullanıcı altında çalıştırın; bu hesap sınırı, korumanın ilk ve en düşük maliyetli 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; hatta sandbox'ın varsayılan politikası, siz reddedene kadar kimlik bilgisi yollarının okunmasına izin verir. Bu nedenle ajanı kendi kullanıcısı altında çalıştırın, kendi ev dizininizi 750 veya daha kısıtlayıcı bir modda tutun, sandbox ayarlarından kimlik bilgisi yollarını engelleyin ve üretim ortamına ait gizli verileri makinede hiç bulundurmayın. Sandbox'ın hiçbir zaman erişemediği bir gizli veri, okunamaz veya sızdırılamaz.

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

Yalnızca ajan çalışmaları için kullanılan, on dakikada güvenliği sıkılaştırılmış, temiz bir snapshot'ı alınmış, Claude Code'u yetkisiz bir kullanıcı altında çalıştıran, API anahtarını 600 modunda bir dosyada tutan, depo bazlı deploy anahtarları kullanan ve tüm çalışmaları birleştirmeden önce gözden geçirdiğiniz dallarda yürüten düşük maliyetli bir VPS kullanmaktır. Bir işlem hatalı giderse, tek bir token'ı iptal edip snapshot'ı geri yüklersiniz; böylece sahip olduğunuz diğer hiçbir şey etkilenmez.