Kodlama ajanı izin modu: plan mı, auto-edit mi, tam erişim mi?

Kodlama ajanında en geniş izni açmak işi hızlandırabilir, ama yanlış komutun etki alanını da büyütür. Her adımı onaya bağlamak ise güvenli görünse bile uzun görevlerde insanı otomatik olarak "onayla" düğmesine basan bir ara katmana çevirebilir. Daha iyi varsayılan, izni görevin yapacağı değişikliğe göre seçmektir.

Kısa cevap: tanımadığın depoda plan veya read-only ile başla. Sınırı belli, Git altında ve test edilebilir bir değişiklikte çalışma alanına yazma izni ver. Paket kurma, ağ erişimi, migration, secret, deploy ve üretim işlemlerini ayrı onay kapısında tut. Tam erişimi yalnızca silinebilir bir container ya da VM içinde, geri dönüş yolu hazırken düşün.

Üç araçta aynı isimler kullanılmıyor

OpenAI, Codex'te sandbox ile onay politikasını iki ayrı kontrol olarak tanımlıyor. Sandbox teknik olarak nereye yazılabileceğini ve ağa çıkılıp çıkılamayacağını belirliyor; onay politikası ise ajanın ne zaman durup kullanıcıya soracağını belirliyor. Codex'in yerel Auto ayarı çalışma alanında okuma, düzenleme ve komut çalıştırmaya izin veriyor; alan dışına yazma veya ağ erişimi için onay istiyor. OpenAI'nin "dangerous full access" seçeneği sandbox ve onay sınırlarını kaldırdığı için önerilen varsayılan değil.[1]

Anthropic'in güncel dokümanında Manual (`default`) yalnızca okumayı otomatik geçiriyor. `acceptEdits` dosya düzenlemelerini ve bazı dosya sistemi komutlarını, `plan` keşif ve planlamayı, `auto` ise arka plandaki güvenlik sınıflandırıcısının onayladığı eylemleri ilerletiyor. Anthropic, `bypassPermissions` modunu yalnızca izole container ve VM'ler için konumlandırıyor. Bunlar Anthropic'in ürün davranışı ve kullanım önerileri; her projede hatasız çalışma garantisi değil.[2][3]

Gemini CLI'da `default` araç çağrılarında onay istiyor, `auto_edit` düzenleme araçlarını otomatik onaylıyor, `plan` salt-okunur çalışıyor. `yolo` bütün araç çağrılarını otomatik geçiriyor ve yalnızca komut satırından açılabiliyor. Google'ın Plan Mode dokümanı bu modu değişiklik yapmadan kod tabanını araştırmak ve uygulama planını onaylatmak için tanımlıyor.[4][5]

Bu adları bire bir eşleştirmek hata olur. "Auto" bir araçta çalışma alanı sandbox'ı, diğerinde ayrı bir sınıflandırıcı anlamına gelebiliyor. Kararı mod adından değil, dört yetkiden ver: okuma, dosyaya yazma, komut çalıştırma ve ağ/dış sistem erişimi.

Hangi görevde hangi izin?

1. Bilmediğin depo, mimari karar veya hata araştırması

Plan/read-only seç. Ajan kodu ve yapılandırmayı okusun, olası etki alanını çıkarsın ve değişiklik planı hazırlasın. Henüz dosya yazmasına gerek yok. Bu mod özellikle "önce sorunu bul, sonra yaklaşımı karşılaştıralım" dediğin görevlerde iyi çalışır.

Geçiş ölçütü basit: değişecek dosyaları, çalışacak testleri ve geri alma yolunu isimlendirebiliyorsan yazma aşamasına geç. Plan hâlâ "ilgili yerleri güncelle" gibi belirsizse izni büyütme.

2. Sınırı belli yerel değişiklik

Çalışma alanına yazma veya auto-edit iyi varsayılandır. Örnekler: mevcut deseni izleyen bir test eklemek, tek bir bileşeni düzeltmek, yerel refactor yapmak ya da lint hatasını gidermek.

Burada koruma modun adı değil, depo sınırıdır. Görev ayrı branch'te olsun; kabul ölçütü ve test komutu promptta yazsın; `.env`, anahtar dosyaları ve çalışma alanı dışı yollar kapalı kalsın. Ajan düzenleyebilsin, ama deploy veya dış servise yazamasın.

3. Paket kurulumu, ağ erişimi, migration veya deploy

On-request/manual kapısını koru. `npm install`, bilinmeyen bir script, veritabanı migration'ı, Git push, CMS yayını ve bulut dağıtımı aynı riskte değildir; fakat hepsi yerel diff'in dışına taşan yan etki üretir.

Bu aşamada tek bir "devam et" yerine eylem bazlı onay daha yararlı: hangi komut çalışacak, hangi hedef değişecek, geri alma yöntemi ne? Ajanın açıklaması ikna edici olsa bile secret erişimini, üretim yazmasını veya geniş ağ yetkisini topluca verme.

4. Uzun ve gözetimsiz CI işi

İzin listesini daralt, ortamı izole et. Claude Code'un `dontAsk` modu önceden izin verilmiş araçlarla kilitli CI için sunuluyor; Codex de read-only ve hiç sormayan ya da workspace-write sınırında çalışan non-interactive kombinasyonlar belgeliyor. Vendor önerileri burada aynı noktaya çıkıyor: gözetimsiz çalışma, sınırsız ana makine erişimi demek değil.[1][2]

Runner tek kullanımlık olsun. Sadece gereken komutları ve hedefleri aç. Tokenları kısa ömürlü ve en düşük yetkili tut. Çıktıyı PR veya artifact olarak üret; üretime doğrudan yazmayı ayrı bir sistem onayına bağla.

5. Tam erişim

Günlük geliştirme modu değil, istisnadır. Tam erişim ancak ortam zaten feda edilebilir durumdaysa anlamlı: tek kullanımlık container/VM, hassas veri yok, dar ağ politikası var ve işlem sonunda ortam siliniyor.

Kendi ana makinen, kişisel home dizinin veya üretim kimlik bilgileri bulunan bir runner bu kategoriye girmez. Tam erişim bir modelin daha iyi düşünmesini sağlamaz; yalnızca yanlış kararın daha uzağa ulaşmasına izin verir.

Beş soruluk seçim kuralı

1. Ajan yalnızca okuyup planlayarak işi ilerletebilir mi? Evetse plan/read-only kullan.

1. Yanlış düzenlemeyi `git diff` ve testler hızlıca yakalar mı? Evetse çalışma alanına yazma veya auto-edit kullan.

1. İş ağ, paket, secret, migration, push ya da deploy içeriyor mu? O eylemi ayrıca onayla.

1. Görev gözetimsiz mi çalışacak? Komut ve hedef allowlist'i ile izole runner kullan.

1. Ortam silinip yeniden kurulabilir mi? Hayırsa tam erişim verme.

İzin, model ve reasoning üç ayrı seçimdir. Önce GPT-5.6 Sol–Terra–Luna ana rehberinden görev için doğru model katmanını seçebilirsin. Terminal ajanını seçmek için Codex CLI–Claude Code–Gemini CLI görev rehberine, teslimden önce de yedi adımlı çıktı doğrulama listesine geç. Daha güçlü model veya high reasoning, gereğinden geniş izni güvenli hâle getirmez.

Singrey notu

Benim varsayılanım sıkıcı ama net: önce plan, sonra yalnız çalışma alanına yazma, en sonda gereken dış eylem için tek tek onay. Tam erişimi hız ayarı gibi görmüyorum. Bir ajan onay istemeden daha çok şey yapabildiğinde iş akışı akıcılaşıyor; aynı anda benim görmediğim bir hatanın hareket alanı da büyüyor. Bu yüzden izin seviyesini ajana duyduğum güvene göre değil, hatayı ne kadar hızlı geri alabileceğime göre seçiyorum.