Workspace trust nedir, repo ajana neyi yaptırabilir?

Workspace trust nedir, bir klasöre güvenince ne açılır?

Hook yazısında ajanın kendiliğinden çalıştırdığı komutları, MCP güvenliği yazısında depoya eklenen sunucuları, sandbox yazısında da ajanın komutlarını neyin sınırladığını anlattık. Bu yazı hepsinin ortak sorusuna bakıyor: bir depoyu kodlama ajanıyla açtığınızda depo ajana ne yaptırabilir? Kısa cevap şu:

Workspace trust birinci yol için var. Klasörü ilk açtığınızda araç “bu klasöre güveniyor musunuz?” diye soruyor ve siz güvenene kadar depodaki ayarların bir kısmını yüklemiyor. VS Code’un belgesine göre amaç, kodun kendiliğinden çalışmasını önlemek; Restricted Mode bu yüzden ajanları, terminali, görevleri, hata ayıklamayı, çalışma alanı ayarlarını ve eklentileri kapatıyor ya da sınırlıyor. Beş araçta güvenene kadar neyin kapalı kaldığı şöyle:

Kaynak: araçların belgeleri ve sürüm notları, 20 Ekim 2026. “Belgesinde yazmıyor”: o gün okuduğumuz sayfalarda bunu anlatan bir cümle bulamadık. Gemini CLI’da karar ~/.gemini/trustedFolders.json’da tutuluyor.

Araçların ortak bir noktası var: güven içeriğe değil, klasöre veriliyor. Claude Code güveni deponun köküne bağlıyor ve bütün depoyu kapsıyor. Copilot CLI’da “bu ve sonraki oturumlar” için güvendiğiniz klasörde soru bir daha gelmiyor; Gemini CLI da her klasör için bir kez soruyor. Yani güvendiğiniz depoya sonradan gelen bir hook, yeni bir soru sorulmadan çalışabilir. Aşağıdaki npm solucanı tam bu yolu kullandı.

VS Code’da bir üst klasöre güvenmek, altındaki her klasöre güvenmek demek. Belge bunu bir düzen olarak öneriyor: güvendiğiniz depoları bir klasörde, tanımadıklarınızı başka bir klasörde tutun ve yalnızca ilkine güvenin. Claude Code’u doğrudan ev dizininizde başlatırsanız güven yalnızca o oturum için tutuluyor, diske yazılmıyor.

Gemini CLI’da durum iki kaynakta farklı yazıyor. Trusted Folders sayfası (23 Nisan’da güncellenmiş) özelliğin varsayılan olarak kapalı olduğunu söylüyor; v0.59.0 sürüm notu (8 Eylül) ise güven politikasını “fail-closed” yaptıklarını yazıyor. Kendi kurulumunuzda security.folderTrust.enabled ayarına bakın. Google, ücretsiz kullanıcılar ile Google AI Pro ve Ultra aboneleri için Gemini CLI’ın hizmetini 18 Haziran 2026’da durdurup Antigravity CLI’a yönlendirdi; ücretli API anahtarıyla Gemini CLI’ı kullanmaya devam edebilirsiniz.

Bir depo hangi dosyalarla kod çalıştırabilir?

Kodlama ajanı bir klasörü açtığında birkaç dosya kendiliğinden kod çalıştırabiliyor. Bunların çoğu commit’le depoya giriyor ve pull request’in diff’inde görünüyor. Biri hiçbir diff’te görünmüyor:

Aynı dosyayı birden çok araç okuyabiliyor: Copilot CLI depodaki .claude/settings.json’ı da okuyor, Cursor CLI da Claude Code’un hook’larını kendi hook’larıyla birleştiriyor. Hook’ları hook yazısında, MCP dosyalarını MCP yazısında ayrıntılı anlattık. Burada saldırganların bu dosyaları nasıl kullandığına bakıyoruz; iki örnek de Ağustos ve Eylül’den.

Aikido’nun raporuna göre 4 Ağustos’ta saldırganlar keyv kütüphanesinin bakımcısının GitHub hesabını ele geçirdi ve paketlere kimlik bilgisi çalan bir solucan koydu. Ertesi gün en az 444 paket ve 1.381 sürüm etkilenmişti. Solucan, çaldığı bilgiler arasında bir GitHub App token’ı bulursa ulaşabildiği depolara, depo başına 50 branch’e kadar commit atıyordu. Bu commit’ler .claude/settings.json’a ve .vscode/tasks.json’a hook ekliyordu; yazarı claude, mesajı chore: update config idi.

Elastic Security Labs’in analizine göre Claude Code’a eklenen, her yeni oturumda çalışan bir SessionStart hook’uydu; VS Code’a eklenen de klasör açılınca çalışan bir folderOpen göreviydi. Elastic’in vardığı sonuç: geliştiricinin bulaşması için depoyu açması yetiyor. Aikido’ya göre npm install bile gerekmiyordu.

Güven sorusu burada devreye girmeyebilir: güven klasöre bir kez veriliyor, yeni hook ise her gün açtığınız bir depoya commit’le geliyor. VS Code’da bir engel daha var: otomatik görevler güvenilmeyen klasörde hiç çalışmıyor, güvendiğiniz klasörde de varsayılan olarak bir kez izin istiyor. Pull request’te yakalanabilecek yer ise diff’in kendisi: .claude/settings.json’a hook ekleyen bir “config güncellemesi”. Commit’in yazarı da mesajı da sıradan görünüyordu; içeriğe bakın.

İkinci örnek, commit’le gelmeyen dosya. Manifold Security’nin 1 Eylül’de yayımladığı GitSpawn araştırmasına göre kodlama ajanları bağlam toplamak için arka planda git komutları çalıştırıyor; bazıları bunu daha siz bir şey yazmadan, güven sorusundan da önce yapıyordu. git status gibi komutlar index’i yenilerken core.fsmonitor ayarındaki programı çalıştırıyor ve git bu ayarı deponun kendi .git/config dosyasından okuyor. Manifold’un anlattığı sonuç: depo bir komutun adını veriyor, git de onu sizin yetkinizle, sandbox’ın dışında ve hiçbir onay sorusu olmadan çalıştırıyor.

Dosyanın nasıl geldiği önemli. Manifold’a göre depoyu kötü niyetli bir adresten klonlamak bu açığı tetiklemiyor, fetch ve pull da tetiklemiyor; git bu ayarı taşımıyor. Saldırının işlemesi için depo kendi .git klasörüyle gelmeli: bir zip dosyasıyla, ortak sürücüyle, senkronize bir klasörle ya da USB bellekle. Araştırmanın kuralı tek cümle: bir programın adını taşıyan her ayar o programı çalıştırabilir. Yayın gününde 8 bulgunun 4’ü düzeltilmişti; kullandığınız aracın sürüm notlarına bakın. Bu dosya hiçbir diff’te görünmüyor ve güven sorusundan önce çalışabiliyor; ona ancak klasör elinize geldiğinde bakabilirsiniz.

CI’da çalışan ajan güven sorusunu sorar mı?

Sormuyor; soracak kimse yok. Araçlar arasındaki fark, sorunun yerine ne yaptıklarında: kimi proje ayarını kullanıyor, kimi hiç yüklemiyor, kimi duruyor. Pull request’leri CI’da bir ajana inceletiyorsanız bu tabloya bakın:

Kaynak: araçların belgeleri ve sürüm notları, 20 Ekim 2026. “Belgesinde yazmıyor”: o gün okuduğumuz sayfalarda bunu anlatan bir cümle bulamadık. Cursor CLI bu davranışa Ocak 2026’da geçti. Gemini CLI, klasör güveni açıkken etkileşimsiz koşuyu FatalUntrustedWorkspaceError ile durduruyor.

Claude Code’un izin belgesi bu durumu kendi tablosunda gösteriyor. Hiç güvenilmemiş bir klasördeki claude -p koşusunda allow kuralları kullanılmıyor, ama ayar dosyasının hook’ları ve env bloğu kullanılıyor. MCP tarafını MCP yazısında anlattık. Belge, yazmadığınız bir depo için ne yapacağınızı da yazıyor: --setting-sources user ile Claude Code projenin ayar dosyalarını hiç okumuyor; --bare ile projeden hook, skill, alt ajan ve eklenti okumuyor, ama projenin env bloğu yine uygulanıyor. Hook’ları kapatmak için disableAllHooks’u o koşuya --settings ile verin. Belgeye göre bunu yalnızca kendi kullanıcı ayarınıza yazmak yetmiyor, çünkü projenin ayarı sizinkini ezip yeniden false yapabiliyor.

Copilot CLI’da bir değişkene dikkat edin: COPILOT_ALLOW_ALL tam olarak true ise CLI klasöre sormadan güveniyor ve kabuk komutu çalıştıran hook’lar dahil depodaki her şeyi yüklüyor. Bir iş akışında bu değişkeni görürseniz işin pull request’in branch’inde çalışıp çalışmadığına bakın. Codex’in belgesi de CI için ayrı bir uyarı yapıyor: depodaki kodu checkout eden ya da çalıştıran işlerde API anahtarını iş düzeyinde ortam değişkeni yapmayın; build betikleri, testler ve bağımlılıkların kurulum hook’ları onu okuyabilir.

Gemini CLI’da bu boşluk bir güvenlik kaydına dönüştü ve kapandı. GitHub’daki GHSA-wpqr-6v78-jr5g kaydına göre (24 Nisan 2026, kritik, CVSS 10,0) eski sürümler CI’da çalışırken klasöre kendiliğinden güveniyordu. Kayıt riski açıkça adlandırıyor: kullanıcıların gönderdiği pull request’leri inceleyen CI iş akışları. Böyle bir depodaki .gemini/ klasörüne konan ortam değişkenleri uzaktan kod çalıştırmaya yol açabiliyordu. Açık Gemini CLI’ın 0.39.1 sürümünde, run-gemini-cli eyleminin de 0.1.22 sürümünde düzeltildi; artık etkileşimsiz koşuda da klasöre açıkça güvenmeniz gerekiyor.

Prompt injection nedir, bir pull request inceleme botunu kandırabilir mi?

Prompt injection, modelin okuduğu bir metne talimat koyup davranışını değiştirmek demek. OWASP iki türünü ayırıyor: kullanıcının kendi girdisiyle yapılan doğrudan prompt injection ve modelin dışarıdan okuduğu bir web sayfasına ya da dosyaya gizlenen dolaylı prompt injection. OWASP’a göre metnin insana görünmesi de gerekmiyor; modelin okuması yetiyor. Kodlama ajanında bu metin depodaki bir dosya, bir pull request açıklaması, bir issue ya da bir yorum olabilir.

Workspace trust bu yolu kapatmıyor: ajanı bir klasörde çalıştırdığınız anda klasördeki metni de ona okutmuş oluyorsunuz. VS Code’un belgesi bu yüzden incelemediğiniz projeyi Restricted Mode’da açmanızı öneriyor. Ajanın bağlama çektiği her dosya prompt injection’a yol açabilir; Restricted Mode’da ise ajanlar hiç çalışmıyor. Metne karşı elinizde iki şey kalıyor: kuralların nereden okunduğu ve ajanın neye yetkisi olduğu.

Bunun CI’da nereye kadar gidebildiğini GitInject (7 Haziran 2026) gerçek GitHub iş akışlarında ölçtü. Araştırmacılar 4 yapay zekâ sağlayıcısının iş akışı yapılandırmalarını denedi ve 11 saldırı belgeledi. Saldırılar dört türe ayrılıyor: ayar dosyasına enjeksiyon, kimlik bilgisi sızdırma, kararı yönlendirme ve hizmeti aksatma. Denenen her sağlayıcı varsayılan yapılandırmasında en az bir türe açık çıktı. Yazarlara göre en ciddi açıklar modelin davranışından değil, CI altyapısının kimlik bilgilerini ve ayar dosyalarını nasıl ele aldığından çıkıyor.

Bir inceleme botunu kandırmak için talimat yazmak bile gerekmiyor. PRWeaver (3 Ağustos 2026) 10 gerçek depoda, çalıştırılarak doğrulanmış 208 saldırı kurdu ve her birini dört biçimde (832 vaka), 3 inceleme ajanı ve 6 model ayarıyla inceletti. Pull request’ler tek tek incelendiğinde saldırıların %50–%60’ı yakalandı; 24 pull request tek seferde incelendiğinde oran %16–%22’ye indi. Saldırıyı gerçek bir değişikliğin içine koyup ikisini birlikte açıklayan inandırıcı bir açıklama yazmak, yakalama oranını 10–18 puan düşürdü. Saldırıyı commit’lere bölmek ise en çok 5 puan fark yarattı.

Yazarların sonucu şu: gizleme en çok, zararsız ve kötü niyetli değişiklikler inceleyenin önünde birlikte durduğunda ya da açıklamada yazan amaç diff’i makul gösterdiğinde işe yarıyor. Yapay zekânın yazdığı kodu inceleme yazısındaki listede bunun karşılığı bir madde var: açıklamadaki her iddianın diff’te karşılığı olmalı. PRWeaver’dan sonra tersini de sorun: diff’teki her değişikliğin açıklamada bir sebebi var mı?

Bir inceleme botunu kalıcı olarak yönlendirmenin yolu ise kurallarını değiştirmek. Kural dosyası pull request’in branch’inden okunuyorsa, pull request kendi incelemesinin kurallarını da değiştirebilir. Araçların belgeleri bu konuda farklı şeyler yazıyor:

Kaynak: araçların belgeleri, 20 Ekim 2026. “Belgesinde yazmıyor”: o gün okuduğumuz sayfalarda bunu anlatan bir cümle bulamadık.

Ajanın yetkisini daraltmanın bir örneği GitHub Agentic Workflows: ajan salt okunur izinle çalışıyor, açacağı pull request gibi yazma işlemleri hemen uygulanmıyor, bekletiliyor. Belgeye göre bunlar uygulanmadan önce ayrı bir iş çalışıyor ve çıktıda prompt injection girişimi, sızan sır ve kötü niyetli kod arıyor. Kandırılan bir ajan, ancak ona verdiğiniz yetki kadar zarar verebilir.

Tanımadığınız depoda ve pull request’te ne yapmalı?

Toparlarsak: güven sorusu bir kez soruluyor, CI’da hiç sorulmuyor ve metni süzmüyor. Ne yapacağınız duruma göre değişiyor:

• Tanımadığınız depo. Güvenmeyin. VS Code şüphedeyseniz klasörü Restricted Mode’da bırakmanızı, Cursor güvenmediğiniz depoyu sade bir metin düzenleyicide açmanızı öneriyor. Ajanla çalışmanız gerekiyorsa depoyu bir sanal makinede ya da kapsayıcıda açın; Claude Code’un belgesi de sanal makine öneriyor. Sandbox tek başına yetmiyor: Claude Code’da sandbox yalnızca kabuk komutlarını kapsıyor, hook’lar ve MCP sunucuları dışında kalıyor. Ayrıntısı sandbox yazısında.
• Elden gelen klasör. Zip’le, ortak sürücüyle ya da USB bellekle gelen bir klasörde .git varsa, ajanla açmadan önce Manifold’un önerdiği gibi .git/config’i okuyun ya da depoyu kaynağından yeniden klonlayın.
• Fork’tan gelen pull request’i CI’da inceleyen ajan. Ajana proje ayarını yükletmeyin: Claude Code’da --setting-sources user verin; Copilot CLI’da COPILOT_ALLOW_ALL’u, Cursor CLI’da --trust’ı pull request’in branch’inde kullanmayın. GitHub’ın 7 Mayıs 2026 tarihli rehberi permissions: read-all’u makul bir varsayılan sayıyor ve modelin çıktısını asla eval etmemenizi söylüyor. Sırları ajanın adımına koymayın.
• Ayar ya da kural dosyasına dokunan pull request. İkinci bölümdeki dosyalardan birine dokunan bir diff’i güvenlik değişikliği gibi okuyun; GitHub’ın rehberi de CI’ı zayıflatan her değişikliği engelleyici sayıyor. İnceleme botunuz kurallarını pull request’in branch’inden okuyorsa, kural dosyasındaki değişiklik o pull request’in nasıl inceleneceğini de belirliyor; onu da kod gibi okuyun.

Aynı soruları kendi inceleme servisimize de sorduk. Yapay zekâ kod inceleme aracımız diffox, her incelemede depoyu GitHub’dan boş bir klasöre baştan klonluyor; klon .git/config’i taşımadığı için GitSpawn’ın kullandığı yol bize ulaşmıyor. Kurallar, mimari yazısında anlattığımız gibi pull request’in birleşeceği branch’ten okunuyor. Bir fork pull request’inin yazarı diff’i ve dosya adlarını istediği gibi yazabilir; bunlardan yorumumuza geçen metin ise ne bir HTML etiketi açabiliyor ne de link olabiliyor. Bu kural, adımızla görünen bir oltalama linkini, katlanmış bölümü kapatıp sahte bir “sorun yok” bölümü yazmayı ve bir görselle veri sızdırmayı engellemek için var.

Sıkça sorulan sorular

Workspace trust nedir?

Kodlama aracının ya da editörün, bir klasörü ilk açtığınızda “bu klasöre güveniyor musunuz?” diye sorması ve siz güvenene kadar klasördeki ayarların bir kısmını yüklememesi. Amaç, depoya konmuş hook’ların, görevlerin ve MCP sunucularının siz bakmadan çalışmasını önlemek. Claude Code, Codex, GitHub Copilot, Cursor ve Antigravity CLI’da var; Cursor’ın editöründe varsayılan olarak kapalı. Güven klasöre bir kez veriliyor ve klasördeki metnin ajanı yönlendirmesini engellemiyor.

Claude Code’da bir klasöre güvenmek neyi açar?

Claude Code güveni deponun köküne bağlıyor ve bütün depoyu kapsıyor. Güvendikten sonra projenin .claude/settings.json’daki allow kuralları ve ek dizinleri, alt ajanların hook’ları ve MCP sunucuları, depodan gelen eklentiler kullanılıyor; ayar dosyasındaki hook’lar ve env bloğu da oturumda çalışıyor. .mcp.json sunucuları için ayrıca soruluyor. Soru yalnızca etkileşimli oturumda çıkıyor; claude -p ve SDK hiç sormuyor. Ev dizininizde başlatırsanız güven yalnızca o oturum için tutuluyor.

Güvendiğim klasörü nasıl geri alırım?

Araca göre değişiyor. VS Code’da Workspace Trust düzenleyicisini (Workspaces: Manage Workspace Trust) açıp klasörü güvenilen klasörler listesinden silin. Copilot CLI’da ~/.copilot/config.json içindeki trustedFolders listesini düzenleyin. Gemini CLI’da o klasörde /permissions yazın; bütün kararlar ~/.gemini/trustedFolders.json’da. Codex’te ~/.codex/config.toml’da o projenin trust_level değerini untrusted yapın. Claude Code güveni ~/.claude.json’da hasTrustDialogAccepted alanında tutuyor; geri almak için bir komut belgesinde yazmıyor. Cursor’ın ve Antigravity’nin belgelerinde de bu yok.

VS Code workspace trust kapatılır mı?

Kapatılabilir: security.workspace.trust.enabled ayarı (varsayılanı açık) özelliği tamamen kapatıyor, --disable-workspace-trust bayrağı ise yalnızca o oturum için. VS Code’un kendi önerisi tersi: şüphedeyseniz klasörü Restricted Mode’da bırakın, güveni sonra verirsiniz. Restricted Mode’da ajanlar, görevler, hata ayıklama ve terminal kapalı. Sık açtığınız depoları bir üst klasörde toplayıp yalnızca o klasöre güvenebilir, tanımadığınız depoları başka bir klasörde tutabilirsiniz.

Prompt injection nedir?

Modelin okuduğu bir metne talimat gizleyip davranışını değiştirmek. OWASP iki türünü ayırıyor: kullanıcının kendi girdisiyle yapılan doğrudan prompt injection ve modelin dışarıdan okuduğu bir web sayfasına, dosyaya ya da yoruma gizlenen dolaylı prompt injection. Kodlama ajanlarında ikincisi öne çıkıyor: depodaki bir dosya, pull request açıklaması ya da issue metni ajanın bağlamına giriyor. OWASP’a göre metnin insana görünmesi de gerekmiyor; modelin okuması yetiyor.

Bir pull request yapay zekâ kod inceleme aracını kandırabilir mi?

Araştırmalar kandırabildiğini gösteriyor. PRWeaver’da yapay zekâ inceleme ajanları gizlenmiş saldırıların, pull request’ler tek tek incelenince %50–%60’ını, 24 pull request birlikte incelenince %16–%22’sini yakaladı; inandırıcı bir açıklama oranı daha da düşürdü. GitInject’te denenen 4 sağlayıcının hepsi varsayılan yapılandırmasında en az bir saldırı türüne açıktı. Aracınızın kurallarını pull request’in branch’inden mi, birleşeceği branch’ten mi okuduğuna bakın. diffox kuralları birleşeceği branch’ten okuyor; pull request’ten yorumuna geçen metin de etiket ya da link olamıyor.

claude -p ya da CI’da güven sorusu çıkar mı?

Hayır. Claude Code’un belgesine göre claude -p ve SDK oturumları güven sorusunu hiç göstermiyor; depodaki ayar dosyasının hook’ları, env bloğu ve apiKeyHelper kullanılıyor, .mcp.json sunucuları sormadan bağlanıyor. Yazmadığınız bir depoda --setting-sources user ya da --bare ile başlatın; hook’ları kapatmak için disableAllHooks’u --settings ile verin. Copilot CLI’ın -p modu güvenilmeyen klasörde depodaki hook’ları yüklemiyor; Cursor CLI ise --trust verilmedikçe duruyor.