Codex'te Sandbox ve Approval'lar: Read-only, Workspace-write, Full Access ve Auto-review

Sürüm notu: Bu yazı Codex CLI 0.169.0'ı (13 Kasım 2026) anlatır; sandbox modları, approval policy, auto-review, Windows sandbox, ağ erişimi ve rules ayrıntıları 15 Kasım 2026'da learn.chatgpt.com/docs'taki Agent approvals & security, Sandbox, Permissions, Auto-review, Windows sandbox, Rules ve Developer commands sayfalarından kontrol edilmiştir. Bu yazıda resmî belgelerden yararlanılmıştır. Örnek config.toml dosyaları Codex'in resmî JSON şemasıyla doğrulanmış, rules dosyası Python'un ayrıştırıcısıyla ayrıştırılıp içindeki örnek komutlar belgelerdeki prefix eşleştirme kuralına göre kontrol edilmiştir.

Önce Tahmin Et

Sitedeki serilerin ortak örnek uygulaması Bookstore'da (bir online kitapçı) Emre, desktop app'in her dotnet restore'da onay istemesinden sıkıldı ve izin menüsünden Full access'i seçti: "Onay soruları kalksın, Codex nasılsa proje klasörünün dışına çıkamaz." Ayşe ise Approve for me'yi seçti: "Bundan sonra ağ erişimi de açık, Codex paketleri sormadan indirir." Ekip, ağ kurallarını yazdığı .codex/config.toml'u repo'ya commit'lemişti; Ayşe klasöre hiç güven vermemişti.

Tahminin ne? Full access'te Codex hâlâ proje klasörüyle sınırlı mı? Approve for me sandbox'ı genişletir mi? Ve commit'lenmiş ağ kuralları Ayşe'nin makinesinde çalışır mı? Cevaplar arayüz modları ve Bookstore bölümlerinde.

Bu yazı talimata değil teknik sınıra bakıyor. AI araçlarında secret ve prompt injection risklerinin araçtan bağımsız tarafı AI Destekli Geliştirme serisinin beşinci yazısında, Claude Code'daki karşılığı da Claude Code serisinin üçüncü yazısında (/blog/claude-code-permission-modes-settings-sandbox).

İki Ayrı Kontrol: Sandbox ve Approval

Belgeler Codex'in güvenlik modelini iki katman olarak anlatıyor. Sandbox, Codex'in modelin ürettiği komutları çalıştırırken teknik olarak ne yapabileceğini belirliyor: nereye yazabilir, ağa çıkabilir mi. Approval policy ise Codex'in bir işlemden önce ne zaman durup sana soracağını belirliyor. Sandbox yalnız Codex'in kendi dosya işlemlerine değil, çalıştırdığı git, dotnet ya da npm gibi komutlara ve onların alt süreçlerine de uygulanıyor.

Üç sandbox modu var. read-only'de Codex dosya okuyor ve sandbox'ın izin verdiği komutları çalıştırıyor ama dosya düzenleyemiyor. workspace-write'ta çalışma dizini ve geçici klasörler içinde düzenleme yapıp komut çalıştırabiliyor; ağ varsayılan olarak kapalı. danger-full-access'te sandbox yok. Approval tarafında iki seçenek var: on-request'te Codex sandbox içinde serbest çalışıyor, sınırın dışına çıkması gerektiğinde soruyor; never'da hiç sormuyor ve verilen sınırların içinde elinden geleni yapıyor. İkisinin arasında, belirli soru türlerini açık tutup diğerlerini otomatik reddeden bir granular policy de var.

Eski configuration'larda gördüğün approval_policy = "untrusted" emekliye ayrıldı ve belgelere göre bu değer Codex'in açılmasını bile engelleyebiliyor. Her komutun onay istemesini istiyorsan belgelerin geçiş önerisi, approval_policy'yi hiç yazmamak ve kullanıcı dosyasında o projeye trust_level = "untrusted" vermek. Bunun bir yan etkisi var: güvenilmeyen projede proje .codex/ katmanı da yüklenmiyor.

workspace-write'ın yazılabilir kökleri içinde bile korunan yollar var: .git, .agents, .codex ve .aws klasörleri, içindekilerle birlikte, salt okunur. Codex kendi skill'lerini, hook'larını ve sandbox ayarlarını sandbox içinden değiştiremiyor.

Arayüzdeki Modlar ve CLI Bayrakları

Desktop app'te ve IDE extension'da composer'ın altındaki izin menüsü bu iki ayarın hazır birleşimlerini sunuyor; CLI'da aynı seçici /permissions. Belgelere göre en yaygın birleşimler şunlar (-a, approval policy bayrağının kısa yazımı):

Tahmindeki ilk iki sorunun cevabı bu tabloda. Full access, danger-full-access ile never'ın birleşimi: Emre onay sorularıyla birlikte sandbox'ı da kaldırdı ve Codex artık proje klasörüyle sınırlı değil. Belgeler bu modda veri kaybına yol açabilecek yıkıcı işlemler yapılabileceği uyarısını açıkça yazıyor ve onu yalnız dışarıdan sertleştirilmiş bir ortamda, örneğin atılabilir bir VM ya da container'da öneriyor. Approve for me ise sınırı hiç genişletmiyor; sınırı aşmak isteyen işlemleri sana sormak yerine ayrı bir reviewer agent'a gönderiyor. Ayşe'nin paket indirmesi yine bir onay isteği olarak doğuyor, yalnız onu artık reviewer değerlendiriyor.

Tek bir ek klasör gerekiyorsa belgelerin önerisi sandbox'ı kaldırmak değil, --add-dir ile o klasöre yazma izni vermek. --approve-for-me, --sandbox ve --yolo ile birlikte kullanılamıyor.

Auto-review Nasıl Karar Veriyor?

Auto-review yalnız approval etkileşimliyken anlamlı: on-request ya da ilgili soru türünü açık bırakan bir granular policy. never'da incelenecek bir soru zaten yok. Configuration'da karşılığı approvals_reviewer = "auto_review"; varsayılan değer user.

Reviewer, sandbox dışına çıkmak isteyen komutları, prompt kararlı bir rules eşleşmesini, onay gerektiren ağ isteklerini, yazılabilir köklerin dışındaki dosya düzenlemelerini ve onay isteyen MCP (Model Context Protocol; agent'ların dış tool ve veri kaynaklarına bağlandığı açık protokol) tool çağrılarını inceliyor. Zaten izni olan işlemler incelemeden geçmeden çalışıyor. Belgelere göre reviewer gizli verinin güvenilmeyen bir yere gönderilmesini, credential aramayı, kalıcı güvenlik zayıflatmasını ve geri dönüşü zor yıkıcı işlemleri engellemek için tasarlanmış; kritik riskli işlemleri reddediyor. Kompakt bir transcript ile onay isteğinin kendisini görüyor, modelin gizli reasoning'ini görmüyor. Hata durumunda kapalı kalıyor: inceleme kurulamazsa ya da zaman aşımına uğrarsa işlem çalışmıyor.

Bir reddin ardından ana agent'a aynı sonuca dolambaçlı bir yoldan ulaşmaması, ya belirgin biçimde daha güvenli bir yol bulması ya da durup sana sorması söyleniyor. CLI'da çoğu model için art arda 3 ret ya da son 50 incelemede 10 ret turn'ü durduruyor. Bir reddin yanlış olduğunu düşünüyorsan /approve o tek işlemi bir kez yeniden denetiyor; bu deneme de yine reviewer'dan geçiyor. Auto-review ek model çağrısı yaptığı için kullanım limitinden harcıyor; yöneticiler allowed_approvals_reviewers ile kullanımını sınırlayabiliyor.

Platformlarda Sandbox: Windows, WSL 2 ve Diğerleri

Sandbox her işletim sisteminde o sistemin kendi mekanizmasıyla uygulanıyor. macOS'ta Seatbelt, Linux'ta varsayılan olarak bwrap ve seccomp, WSL (Windows Subsystem for Linux; Windows içinde Linux çalıştıran katman) 2'de Linux uygulaması. Linux ve WSL 2'de dağıtımın bubblewrap paketini kurmak gerekiyor. Claude Code'dan farklı olarak Codex'in native Windows'ta da bir sandbox'ı var ve üç uygulaması bulunuyor:

• mxc: uyumlu Windows 11 cihazlarında önerilen seçenek. Yönetici onaylı kurulum, ek Windows hesabı ya da firewall kuralı istemeden native process izolasyonu kullanıyor. Microsoft'un Windows 11 24H2 ve 25H2 için kademeli olarak dağıttığı MXC (Microsoft Execution Containers; Windows'un process izolasyon altyapısı) yeteneklerine ihtiyaç duyuyor.
• elevated: MXC yoksa tercih edilen eski yöntem. Yönetici onaylı bir kurulum istiyor; ayrı düşük yetkili sandbox kullanıcıları, dosya sistemi izinleri ve firewall kurallarıyla çalışıyor.
• unelevated: yönetici kurulumu mümkün değilse son seçenek. Ağ izolasyonu elevated'dan zayıf ve okuması yasaklanan yolları desteklemiyor.

Desktop app, kişisel hesaplarda cihaz destekliyorsa MXC'yi kendiliğinden tercih ediyor. CLI'da bunu kullanıcı dosyasında açıyorsun ve yedek olarak bir eski uygulama bırakıyorsun. Bu makineye özel bir ayar; proje dosyasına değil, %USERPROFILE%\.codex\config.toml'a giriyor:

# Bu makine için Windows sandbox seçimi
[features]
prefer_mxc = true

[windows]
sandbox = "elevated"

Cihazın MXC'yi destekleyip desteklemediğini CLI 0.162 ve sonrasında kayıtlı seçimi değiştirmeden tek bir komutla deneyebiliyorsun. Belgelere göre beklenen sonuç ekrana MXC_OK yazılması ve çıkış kodunun 0 olması:

codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODE

MXC'nin Bookstore'u ilgilendiren iki sınırı var. Host üzerindeki loopback servislerine bağlantıya izin veriyor; ayrıca ön plandaki komut bitince geride kalan alt süreçleri durduruyor, yani Codex'in arka planda başlattığı bir ng serve komut biter bitmez kapanabiliyor. Desktop app'te sandbox'ın uygulanması için mesaj göndermeden önce Ask for approval seçili olmalı.

Ağ Erişimi

Varsayılan workspace-write'ta komutların ağ erişimi kapalı. Açmanın iki aşaması var ve belgeler bunları özellikle ayırıyor. [sandbox_workspace_write] altındaki network_access = true komutlara ağı açıyor ama hedefleri sınırlamıyor. features.network_proxy ise açık olan ağı senin yazdığın domain kurallarıyla sınırlıyor; tek başına ağ açmıyor. Ağ kapalıyken proxy'nin hiçbir etkisi yok, ağ açık ve proxy kapalıyken de dışarıya sınırsız doğrudan erişim var.

Domain kuralları önce izin listesi mantığıyla çalışıyor: tam host adı yalnız kendisini eşliyor, *.example.com alt domain'leri ama apex'i değil, **.example.com ikisini birden eşliyor ve deny her zaman allow'u yeniyor. Loopback ve özel ağ adresleri varsayılan olarak engelli (MXC'de bu varsayılan farklı); tek bir yerel hedef gerekiyorsa tam bir IP adresi ya da localhost kuralı ekleniyor. Proxy'nin filtrelemediği trafik de var: web search, MCP server bağlantıları, tarayıcı ve computer use, cloud task'lar ve Codex'in kendi model istekleri. Web search varsayılan olarak OpenAI'ın tuttuğu bir index'ten cache'lenmiş sonuç döndürüyor; belgelere göre bu, rastgele canlı sayfalardan gelebilecek prompt injection riskini azaltıyor.

Bookstore: Proje Ayarları ve Rules

Bookstore'un .codex/config.toml'u Auto preset'ini açıkça yazıyor ve ağı yalnız paket kaynaklarına açıyor. dotnet restore nuget.org'a, npm ci npm registry'sine gidebiliyor; başka bir adrese giden istek proxy'de kalıyor:

#:schema https://developers.openai.com/codex/config-schema.json
# Bookstore proje ayarları. Codex bu dosyayı yalnız proje güvenilirse yükler.

sandbox_mode = "workspace-write"
approval_policy = "on-request"

# Komutlar ağa çıkabilir, ama yalnız aşağıdaki paket kaynaklarına.
[sandbox_workspace_write]
network_access = true

[features.network_proxy]
enabled = true
domains = { "**.nuget.org" = "allow", "registry.npmjs.org" = "allow" }

[mcp_servers.playwright]
command = "npx"
args = ["-y", "@playwright/mcp@0.0.85"]
startup_timeout_sec = 30
default_tools_approval_mode = "prompt"

Tahmindeki üçüncü sorunun cevabı burada: bu dosya proje katmanında olduğu için yalnız güvenilen projede yükleniyor. Ayşe klasöre güvenmediği sürece commit'lenmiş ağ kuralları, MCP server'ı ve aşağıdaki rules dosyası onun makinesinde hiç devreye girmiyor. /debug-config hangi katmanın yüklendiğini gösteriyor.

API testleri ayrı bir sorun. Bookstore'un testleri geliştiricinin makinesindeki SQL Server'a bağlanıyor. Belgeler MXC'nin host loopback bağlantılarına izin verdiğini yazıyor, ama diğer platformlarda yerel bir veritabanına giden TCP bağlantısının sandbox içinde nasıl davrandığını ayrıca anlatmıyor. Ekip bu yüzden testleri sandbox dışında, her seferinde onayla çalıştırmayı seçti. Rules dosyaları tam bunun için: Starlark (Python'a benzeyen, yan etkisiz çalışan bir configuration dili) ile yazılan prefix_rule'lar bir komut prefix'i için allow, prompt ya da forbidden kararı veriyor. Proje kuralları .codex/rules/ altında:

# Bookstore için Codex komut kuralları (Starlark). Yalnız proje güvenilirse yüklenir.

# API testleri sandbox'ın erişemediği yerel SQL Server'a bağlanıyor: sandbox dışındaki her koşudan önce sor.
prefix_rule(
    pattern = ["dotnet", "test"],
    decision = "prompt",
    justification = "API tests connect to the local SQL Server outside the sandbox. Approve each run.",
    match = [
        "dotnet test",
        "dotnet test tests/Bookstore.Api.Tests --filter Category=Ordering",
    ],
    not_match = ["dotnet build Bookstore.slnx"],
)

# Veritabanı şemasını yalnız developer değiştirir.
prefix_rule(
    pattern = ["dotnet", "ef", "database", ["update", "drop"]],
    decision = "forbidden",
    justification = "The developer applies migrations. Create one with the add-migration skill instead.",
    match = [
        "dotnet ef database update --project src/Bookstore.Api",
        "dotnet ef database drop --force",
    ],
    not_match = ["dotnet ef migrations list --project src/Bookstore.Api"],
)

# İşi yayınlamak her zaman bir kişi ister.
prefix_rule(
    pattern = ["git", "push"],
    decision = "prompt",
    justification = "Pushing publishes the branch. Review the diff first.",
    match = ["git push origin feature/order-paging"],
    not_match = ["git status"],
)

Birden çok kural eşleşirse en kısıtlayıcı karar kazanıyor (forbidden, prompt, allow sırasıyla). match ve not_match listeleri, Codex'in dosyayı yüklerken doğruladığı satır içi testler. bash -lc "git add . && rm -rf /" gibi düz bir komut zinciri parçalarına ayrılıp her parça ayrı değerlendiriliyor; yönlendirme, değişken ya da wildcard içeren script'ler ise tek bir komut sayılıyor. Belgeler bu ayrıştırmayı bash, zsh ve sh sarmalayıcıları için anlatıyor; PowerShell komutları için aynı ayrıştırmadan söz etmiyor. Kuralı denemek için:

codex execpolicy check --pretty --rules .codex/rules/bookstore.rules -- dotnet ef database update

Rules hâlâ experimental olarak işaretli. Terminal arayüzünde (TUI) bir komutu "bir daha sorma" diye onayladığında Codex kuralı proje dosyasına değil, kullanıcı katmanındaki ~/.codex/rules/default.rules'a yazıyor; ekibin değil senin ayarın değişiyor.

Claude Code ile Kavram Eşlemesi

İki aracın kavramları birebir aynı değil; aşağıdaki tablo yalnız yön bulmak için. Claude Code tarafı serinin üçüncü yazısındaki belgelere dayanıyor.

Üretimde Dikkat

Ekip kuralı ile kişisel tercihi ayır. Sandbox ve ağ kuralları projenin .codex/config.toml'unda, Windows sandbox seçimi ve kişisel izinler kullanıcı dosyasında. Kurumsal ortamda yöneticiler requirements.toml ile allowed_sandbox_modes ve allowed_approval_policies gibi sınırlar koyabiliyor; örneğin Full access'i ve never'ı tamamen yasaklayabiliyor.

Permission profile'lar beta. default_permissions ve [permissions.<name>] tabloları dosya ve ağ kurallarını isimli profillerde topluyor, ama belgelere göre eski sandbox ayarlarıyla birleşmiyor: herhangi bir yüklenen dosyada sandbox_mode varsa Codex profili değil eski ayarları kullanıyor. İkisinden birini seç; Bookstore şimdilik kararlı olan sandbox_mode'da kalıyor.

Container sınır olacaksa bunu bilerek yap. Belgeler, Codex'in Docker ya da Dev Container içinde kendi sandbox'ını kuramadığı durumda container'ı dış sınır yapıp içeride danger-full-access kullanmayı anlatıyor; ama o zaman container'daki her şey, Codex'in giriş bilgisi dahil, kötü niyetli bir projeye açık kalıyor. Bu yolu yalnız güvendiğin repo'larda kullan.

Sık Düşülen Tuzaklar

Full access'i host makinede kullanmak. Onay soruları kalkarken sandbox da kalkıyor. Ağa ya da başka bir klasöre ihtiyaç varsa network_access, --add-dir ya da bir prefix_rule yeterli.

Approval'ı kapatınca sandbox'ın da kalktığını sanmak, ya da tersi. -a never sandbox'ı değiştirmiyor; Codex yalnız sormayı bırakıyor ve sınırın içinde kalıyor.

Approve for me'yi geniş izin sanmak. Sınır aynı; yalnız soruları reviewer cevaplıyor ve ek kullanım harcıyor.

Güvenilmeyen dizinde proje ayarlarını beklemek. Ağ kuralları, MCP server ve rules dosyası güven verilmeden yüklenmiyor. 0.169'dan beri codex exec de güvenilmeyen dizinde proje configuration'ını ve MCP server'larını kapalı tutuyor; altıncı yazıda göreceğiz.

Küçük Bir Deneme

★☆☆ Repo'nda /status ile workspace dizinlerini, /debug-config ile hangi configuration katmanlarının yüklendiğini listele. Projeye güven vermeden ve verdikten sonra çıktı nasıl değişiyor?

★★☆ Bookstore'daki rules dosyasını kendi repo'na uyarla ve codex execpolicy check ile üç komutu dene: biri allow, biri prompt, biri forbidden sonuç vermeli. Bir not_match örneğini bilerek yanlış yazıp Codex'in dosyayı yüklerken ne dediğine bak.

★★★ Windows'ta MXC denemesini çalıştır, sonra network_proxy açıkken yalnız nuget.org'a izin ver ve npm ci'ın ne olduğunu izle. Ağ kapalı, ağ açık ve proxy açık üç durumda dotnet restore ve npm ci'ın davranışını bir tabloya yaz.

Sınırlar yerinde olduğunda sıra günlük işe geliyor. Dördüncü yazıda model ve reasoning effort seçimini, worktree'lerle paralel çalışmayı, subagent'ları, hook'ları ve IDE extension'ı Bookstore'a sipariş listesi için CSV (virgülle ayrılmış düz metin tablo formatı) export'u eklerken göreceğiz.