Codex’in dosyaları düzenlemesini, komutları çalıştırmasını ve her adımda sizden onay beklemeden işini sürdürmesini istiyorsunuz. Ancak "Full Access" seçeneğini açtığınızda bile sorular bitmiyor. Codex CLI v0.145.0 üzerinde test ettiğimiz kısa cevap şu: bunun birden fazla izin katmanı var ve gerçekten müdahalesiz kullanım için doğru katmanları birlikte ayarlamanız gerekiyor.
Neden böyle oluyor: "Auto mode" tek bir anahtar değil. Codex’te birbirinden bağımsız iki denetim bulunuyor: sandbox hangi kaynaklara erişebileceğini, approval policy ise hangi noktada durup onay isteyeceğini belirliyor. Ağ erişimi de üçüncü ve ayrı bir kapı. Birini gevşetmek diğerlerini değiştirmiyor; ayrıca Codex güncellemeleri oturumunuzu fark ettirmeden varsayılan politikaya döndürebiliyor.
CLI’da tam müdahalesiz kullanım: Tüm engelleri tek seferde kaldıran tek bayrak --yolo. Sandbox’ı koruyarak daha güvenli ilerlemek istiyorsanız, iki ekseni de açıkça tanımlayın. Ayarı oturumun başında yapın ve her güncellemenin ardından yeniden kontrol edin.
# Gerçekten müdahalesiz — sandbox yok, onay istemi yok (yalnızca geçici ortamda):
codex --yolo
# Daha güvenli — proje içinde serbestçe düzenler, dışarı çıkarken yine sorar:
codex --sandbox workspace-write --ask-for-approval on-requestUygulamada tam müdahalesiz kullanım: onay menüsünü açın, Full access seçeneğini seçin ve her güncellemeden sonra bu seçimi yeniden yapın; yükseltmeler modu sıfırlıyor.
Kısa yanıt bu kadar. Devamında tüm modları, arka planda hangi ayarlara karşılık geldiklerini ve hangi senaryoda hangisini seçmeniz gerektiğini bulacaksınız.
Codex’in üç izin modu karşılaştırması
Sandbox, ajanın neleri kullanabileceğini belirler: dosyalar ve ağ gibi. Approval policy ise hangi aşamada durup onay isteyeceğini yönetir. Auto mode, bu iki ayarın hazır eşleşmesinden ibaret; masaüstü uygulaması ile CLI aynı eşleşmeleri farklı adlarla sunuyor.
| Uygulamadaki ad | Ne yapar? | CLI karşılığı |
|---|---|---|
| Ask for approval | Çalışma alanındaki dosyaları düzenler, rutin yerel komutları çalıştırır; internete erişmeden veya çalışma alanı dışına çıkmadan önce sorar | sandbox_mode = "workspace-write" + approval_policy = "on-request" |
| Approve for me (uygulamanın mevcut varsayılanı) | Aynı sınırlar korunur, ancak uygun onay istemleri size değil bir AI inceleyicisine gider (Auto-review budur) | yukarıdaki + approvals_reviewer = "auto_review" |
| Full access | Sandbox ve onay istemi yoktur; dosya ve ağ erişimi sınırsızdır | sandbox_mode = "danger-full-access" + approval_policy = "never" |
CLI kullananlar bu ayarları doğrudan --sandbox ve --ask-for-approval ile yapabilir; oturum sırasında hazır ayar değiştirmek için de /permissions seçicisini kullanabilir. Henüz hangi istemciyi kullanacağınıza karar vermediyseniz, bu ayrı bir konu; Codex ve Claude Code karşılaştırmasını burada yayımladık. Bu yazının odağı ayarların kendisi.
"Full Access" açıkken Codex neden hâlâ onay istiyor?
Bunun üç nedeni var ve birbirini tamamlıyor.
Sandbox ile onay politikası ayrı ayarlardır. workspace-write + on-request, Codex’in proje içinde serbestçe düzenleme yapmasına izin verir; ancak ağ çağrısı, repo dışındaki bir dosya ya da sudo gibi proje sınırını aşan işlemlerde durur. Sandbox’ı gevşetip onayları isteğe bağlı bırakırsanız, her sınır geçişinde istem görmeye devam edersiniz.
Ağ erişimi ayrı bir kapıdır. Full Access, interneti dosya sisteminden ayrı olarak yine de kısıtlayabilir. @mxcl’nin belirttiği gibi (16 Temmuz 2026), Codex "cannot use the Internet without full access, ending task until the user enables full access." Dosya yazma izni ile ağ erişimi aynı izin değildir.
Güncellemeler modu sıfırlar. Temmuz 2026’nın sonlarında birden fazla kullanıcı bu durumla karşılaştı: Codex yükseltmesi, aktif oturumları sessizce varsayılan politikaya geri alıyor. @s_rafcon’un 22 Temmuz’daki ifadesiyle, iş parçacıkları "switch their Full access flag to the default flag and [are] stuck asking for approval on every single edit." Modu oturumun başında ayarlayın ve her güncellemenin ardından tekrar kontrol edin.
CLI’da --full-auto kaldırıldı: Yerine ne kullanmalısınız?
codex --full-auto, eskiden "projemde onay sormadan çalış" kısayoluydu: approval_policy = "on-request" + sandbox_mode = "workspace-write". Ancak etkileşimli komut artık bu bayrağı kabul etmiyor. v0.145.0 üzerinde test sonucu şöyle:
$ codex --full-auto
error: unexpected argument '--full-auto' foundBunun yerine iki ekseni doğrudan ayarlayın; eski bayrağın yaptığı tam olarak buydu:
# --full-auto için güncel karşılık
codex --sandbox workspace-write --ask-for-approval on-request
# Ya da etkileşimsiz kullanımda, istem olmadan fakat sandbox korunarak:
codex -a never -s workspace-write exec "your task"codex exec --full-auto, betikler için bayrağı hâlâ kabul ediyor; hata yalnızca etkileşimli komutta görülüyor. codex --help çıktısına göre --ask-for-approval, untrusted / on-request / never değerlerini; --sandbox ise read-only / workspace-write / danger-full-access değerlerini alıyor. Uygulamadaki her "mod", bu iki ayarın bir birleşimi.
--yolo ne zaman doğru tercih olur?
--yolo, --dangerously-bypass-approvals-and-sandbox seçeneğinin kısa takma adı. Gerçek anlamda "bırak çalışsın" anahtarı budur: danger-full-access ile never ayarlarını birleştirir; dosya sistemi sınırı da onay kapısı da kalmaz. --full-auto kaldırılmışken bu seçeneğin korunmasının nedeni de adının riski açıkça anlatması. v0.145.0’da codex --yolo sorunsuz çalışırken, codex --full-auto hata veriyor.
Deneyimli kullanıcıların önemli bir bölümü bunu varsayılan olarak çalıştırıyor ve doğru görevlerde haklılar: koruma mekanizması ortamın kendisiyse kullanılabilir. Makineyi gözden çıkarılabilir kabul edin:
- Günlük kullandığınız bilgisayarda değil, geçici bir VM veya geliştirme container’ında çalıştırın.
- Önce üretim ortamı kimlik bilgilerini ortamdan kaldırın.
- Görevi dar kapsamlı tutun, sonra devam etmeden önce
git diffçıktısını inceleyin.
--yolo her kapıyı kaldırdığı için, yanlışlıkla tetiklenen bir rm -rf, git push veya DROP TABLE komutu onay istenmeden çalışır; hızın bedeli budur. (Codex’i özel bir model sağlayıcısı üzerinden self-hosted veya Anthropic-compatible bir endpoint’e yönlendirmeniz bu durumu değiştirmez; sandbox, API’nin arkasındaki modelle ilgilenmez.)
"Approve for me" / Auto-review: Onayı bir AI ajana devretmek
En yeni mod ve uygulamanın mevcut varsayılanı Auto-review. Uygun yükseltme istekleri, gerekçesiyle birlikte onay veya ret kararı veren ayrı bir inceleyici ajana yönlendirilir: GPT-5.4 Thinking (low) kullanan küçük bir Codex. OpenAI bunu "izin verme değil, inceleyici değişimi" olarak tanımlıyor: yazılabilir dizinleri genişletmez veya ağı açmaz; yalnızca onayı kimin verdiğini değiştirir.
OpenAI’nin 30 Nisan 2026 tarihli kendi değerlendirmesine göre Auto-review, manuel onaya kıyasla insanı yaklaşık 200x daha az durduruyor ve incelediği yükseltmelerin yaklaşık %99,1’ini onaylıyor (tüm eylemler genelinde %99,93). 10.000 eylemlik örnek senaryoda 9.280 eylem sandbox içinde doğrudan çalıştı, 720’si inceleyiciye takıldı ve yalnızca 7’si reddedildi.
Arka arkaya retlerin süreci kilitlemesini önleyen korumalar da var: art arda 3 ret sonrasında veya son 50 incelemeyi kapsayan kayan pencerede 10 ret görüldüğünde tur kesiliyor. Sistem sizi durdurursa /approve komutunu çalıştırarak Auto-review Denials seçicisini açabilir ve yeniden deneme için tek bir eyleme izin verebilirsiniz.
Ancak bu güvenlik kontrolleri uzun çalışmaları aksatabiliyor. Temmuz 2026 sonunda, çok saat süren /goal görevlerini kullanan kişiler, düzenli aralıklarla gelen "keep waiting?" isteminin eskiden günler boyunca gözetimsiz çalışabilen akışları bozduğunu bildirdi. OpenAI de bunun "should not be treated as a guarantee of security" olduğunu açıkça söylüyor: red-team geri çağırma oranı yüksek olsa da kusursuz değil (%90,3 overreach, %99,3 prompt injection, %96,1 misaligned-model). İyi bir varsayılan, fakat yüksek riskli işlerde sandbox’ın yerine geçmez.
Arayüz yerine yapılandırma dosyasından etkinleştirmek için:
approvals_reviewer = "auto_review"
[auto_review]
policy = """
Describe what the reviewer should allow or block here.
"""Pratikte hangi modu seçmelisiniz?
- Günlük yerel geliştirme:
workspace-write+on-request("Ask for approval"). Repo dışına çıkacak işlemler için son sözü siz söylersiniz; asıl risk de genellikle burada ortaya çıkar. - Uzun ve gözetimsiz çalıştırmalar: "Approve for me" (Auto-review). İşaretlediği eylemlerde yine duracağını unutmayın; bu mod tamamen sıfır dokunuşlu değil.
- Geçici bir ortamda tek seferlik riskli işler:
--yolo. En hızlı ve en tehlikeli seçenek; yalnızca ortam zarar görmeyecek durumdaysa güvenlidir. - Bir kod tabanını okumak veya incelemek:
read-only. Yazma yok, sürpriz yok.
Dürüst özet şu: Hem tamamen otonom hem de tamamen güvenli bir ayar yok. Müdahalesizliğe yaklaştığınız her adımda kendi muhakemenizin bir bölümünü bir sınıflandırıcının kararına bırakırsınız. Bu takas rutin işler için anlamlı olabilir; üretim altyapısında ise kötü bir fikirdir. Ayarı bir kez ve kalıcı olarak değil, göreve göre seçin.
Sık sorulan sorular
Codex için auto mode var mı?
Evet, ancak tek bir düğme yerine hazır ayar grupları var. Uygulamada "Ask for approval", "Approve for me" ve "Full access" auto mode seçeneklerini oluşturuyor. CLI’da ise aynı davranışı --sandbox ve --ask-for-approval parametreleriyle kurabilir veya /permissions kullanabilirsiniz.
Codex’in tüm komutları otomatik onaylamasını nasıl sağlarım?
approval_policy = "never" ayarını kullanın. workspace-write ile eşleştiğinde sandbox içindeki istemleri durdurur; danger-full-access ile eşleştiğinde, yani --yolo kullanımında, tüm istemleri tamamen kaldırır. İkinci seçenek tüm korumaları devre dışı bırakır; bu nedenle yalnızca izole bir ortamda çalıştırın.
Codex auto-review modu nedir?
Auto-review (approvals_reviewer = "auto_review"; arayüzde "Approve for me" olarak görünür), onay kararlarını size yöneltmek yerine bir AI inceleyici ajana yollar. İncelediklerinin yaklaşık %99’unu onaylar ve insanı yaklaşık 200x daha az durdurur; ancak güvenlik garantisi değildir.
--full-auto hâlâ çalışıyor mu?
Etkileşimli CLI’da hayır. v0.145.0 üzerinde yapılan testte codex --full-auto, "unexpected argument" hatasını döndürüyor. codex exec --full-auto ise betikler için kullanımdan kaldırılmış bir takma ad olarak hâlâ kabul ediliyor. Etkileşimli kullanımda bunun yerine --sandbox workspace-write --ask-for-approval on-request ayarını yapın.
--yolo modu güvenli mi?
Hayır. Zaten adının amacı da bu riski vurgulamak. Sandbox’ı ve tüm onayları aynı anda devre dışı bırakır. Yalnızca üretim kimlik bilgilerinin kaldırıldığı, gözden çıkarılabilir bir VM veya container içinde ve dar kapsamlı görevlerle makul bir seçenektir.