Ajan onayları ve güvenlik

Codex, kodunuzu ve verilerinizi korumaya yardımcı olur ve kötüye kullanım riskini azaltır.

Ajan, varsayılan olarak ağ erişimi kapalı şekilde çalışır. Codex yerel olarak, erişebileceği yerleri (genellikle geçerli çalışma alanıyla) sınırlayan işletim sistemi tarafından zorunlu kılınan bir korumalı alanın yanı sıra, işlem yapmadan önce ne zaman durup sizden izin istemesi gerektiğini belirleyen bir onay politikası kullanır.

Korumalı alanın ChatGPT masaüstü uygulaması, Codex CLI ve IDE uzantısında nasıl çalıştığına ilişkin genel bir açıklama için korumalı alan sayfasına bakın. Daha kapsamlı bir kurumsal güvenlik özeti için Codex güvenlik teknik incelemesine bakın.

Korumalı alan ve onaylar

Codex güvenlik denetimleri birlikte çalışan iki katmandan oluşur:

• Korumalı alan modu: Codex'in model tarafından oluşturulan komutları yürütürken teknik olarak neler yapabileceğini (örneğin nereye yazabileceğini ve ağa erişip erişemeyeceğini) belirler.
• Onay politikası: Codex'in bir işlemi yürütmeden önce ne zaman sizden izin istemesi gerektiğini (örneğin korumalı alanın dışına çıkma, ağı kullanma veya güvenilen bir kümenin dışındaki komutları çalıştırma) belirler.

Codex, nerede çalıştırıldığına bağlı olarak farklı korumalı alan modları kullanır:

• Codex cloud: OpenAI tarafından yönetilen yalıtılmış kapsayıcılarda çalışarak ana sisteminize veya ilgisiz verilere erişimi engeller. İki aşamalı bir çalışma zamanı modeli kullanır: kurulum, ajan aşamasından önce çalışır ve belirtilen bağımlılıkları yüklemek için ağa erişebilir; ardından ajan aşaması, söz konusu ortam için internet erişimini etkinleştirmediğiniz sürece varsayılan olarak çevrimdışı çalışır. Bulut ortamları için yapılandırılan gizli bilgiler yalnızca kurulum sırasında kullanılabilir ve ajan aşaması başlamadan önce kaldırılır.
• Codex CLI / IDE uzantısı: Korumalı alan politikaları işletim sistemi düzeyindeki mekanizmalarla uygulanır. Varsayılan ayarlar arasında ağ erişiminin olmaması ve yazma izinlerinin etkin çalışma alanıyla sınırlı tutulması bulunur. Korumalı alanı, onay politikasını ve ağ ayarlarını risk toleransınıza göre yapılandırabilirsiniz.

Auto ön ayarında (örneğin --sandbox workspace-write --ask-for-approval on-request) Codex, çalışma dizinindeki dosyaları otomatik olarak okuyabilir, düzenleyebilir ve komutları çalıştırabilir.

Codex, çalışma alanı dışındaki dosyaları düzenlemek veya ağ erişimi gerektiren komutları çalıştırmak için onay ister. Değişiklik yapmadan sohbet etmek veya planlama yapmak istiyorsanız /permissions komutuyla read-only moduna geçin.

Codex ayrıca işlem bir kabuk komutu veya dosya değişikliği olmasa bile yan etkileri olduğunu bildiren uygulama (bağlayıcı) aracı çağrıları için onay isteyebilir. Araç, yıkıcı işlem ek açıklaması bildiriyorsa, başka ipuçları (örneğin salt okunur ipuçları) da bildirse bile yıkıcı uygulama/MCP aracı çağrıları her zaman onay gerektirir.

Ağ erişimi

Codex cloud için tam internet erişimini veya bir etki alanı izin listesini etkinleştirmek üzere ajan internet erişimi sayfasına bakın.

ChatGPT masaüstü uygulaması, Codex CLI veya IDE uzantısında varsayılan workspace-write korumalı alan modu, yapılandırmanızda etkinleştirmediğiniz sürece ağ erişimini kapalı tutar:

[sandbox_workspace_write]
network_access = true

Ağ yalıtımı

Ağ erişimi; komutların başlattığı betiklere, programlara ve alt süreçlere uygulanan hedef kurallarıyla denetlenir. Komutların ağ erişimi zaten etkinse bu trafiği yapılandırdığınız ağ politikasıyla sınırlandırmak için network_proxy özelliğini açın.

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

Tek seferlik bir CLI oturumunda yalnızca açma-kapama anahtarına ihtiyacınız varsa Boole kısaltmasını, politika seçeneklerini de ayarlıyorsanız tablo biçimini kullanın:

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

codex \
  -c 'features.network_proxy.enabled=true' \
  -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \
  -c 'sandbox_workspace_write.network_access=true'

Bu özellik, etkin ağ erişiminin nasıl uygulandığını değiştirir; tek başına ağ erişimi sağlamaz. Komutların ağ erişimine sahip olup olmayacağını belirlemek için sandbox_workspace_write.network_access ile workspace-write yapılandırmasını kullanın:

• Ağ kapalı + network_proxy açık: Ağ kapalı kalır ve özellik hiçbir şey yapmaz.
• Ağ açık + network_proxy kapalı: Ağ, kısıtlanmamış doğrudan giden erişimle açık kalır.
• Ağ açık + network_proxy açık: Ağ açık kalır ve giden trafik yapılandırılmış ağ politikasıyla sınırlandırılır.

Yönetici tarafından yönetilen experimental_network gereksinimleri, kullanıcı özelliği anahtarından ayrıdır. Korumalı alan ağını features.network_proxy olmadan yapılandırıp başlatabilirler ancak etkin korumalı alan ağı kapalı tutuyorsa ağ erişimini açmazlar. Yönetici tarafındaki requirements.toml yapısı için Yönetilen yapılandırma sayfasına bakın.

Ağ politikası

Etki alanı kuralları önce izin listesi yaklaşımını kullanır:

• Tam ana makine adları yalnızca kendileriyle eşleşir.
• *.example.com, api.example.com gibi alt etki alanlarıyla eşleşir ancak example.com ile eşleşmez.
• **.example.com hem kök etki alanıyla hem de alt etki alanlarıyla eşleşir.
• Genel bir * izin kuralı, reddedilmemiş tüm genel ana makinelerle eşleşir. * kuralını geniş ağ erişimi olarak değerlendirin ve mümkün olduğunda kapsamı sınırlandırılmış kuralları tercih edin.
• deny her zaman allow karşısında önceliklidir ve genel * yalnızca izin kuralları için geçerlidir.

Yerel ve özel hedefler

allow_local_binding = false varsayılan olarak geri döngü, bağlantı-yerel ve özel hedefleri engeller:

• Belirli istisnalar: Bir komut tek bir yerel hedefe ihtiyaç duyduğunda tam bir yerel IP sabiti veya localhost izin kuralı ekleyin.
• Daha geniş erişim: allow_local_binding = true değerini yalnızca bilerek daha geniş yerel/özel erişim istediğinizde ayarlayın.
• Joker karakterler: Joker karakterli kurallar açık yerel istisnalar sayılmaz.
• Çözümlenen adresler: İzin listesiyle eşleşseler bile yerel/özel IP'lere çözümlenen ana makine adları engellenmeye devam eder.

DNS yeniden bağlama korumaları

Codex, bir ana makine adına izin vermeden önce elinden geldiğince DNS ve IP sınıflandırma denetimi gerçekleştirir:

• Başarısız olan veya zaman aşımına uğrayan sorgular engellenir.
• Genel olmayan adreslere çözümlenen ana makine adları engellenir.
• Denetim, DNS yeniden bağlama riskini azaltır ancak tamamen ortadan kaldırmaz. Yeniden bağlamayı tamamen önlemek, çözümlenen IP'lerin taşıma katmanı boyunca sabitlenmesini gerektirir.

Kötü amaçlı DNS kapsam dâhilindeyse giden trafik denetimlerini daha alt bir katmanda da uygulayın.

Tehlikeli ayarlar

İki ayar güven sınırını bilinçli olarak genişletir:

• dangerously_allow_non_loopback_proxy = true, proxy dinleyicilerini geri döngünün ötesine açabilir.
• dangerously_allow_all_unix_sockets = true, Unix soketi izin listesini atlar.

Bunları yalnızca sıkı denetlenen ortamlarda kullanın. Unix soketi proxy'lemesi etkinleştirildiğinde, geri döngü dışı bağlama istenmiş olsa bile dinleyiciler yalnızca geri döngüde kalır; böylece korumalı alan ağı, yerel daemon'lara uzaktan erişim köprüsüne dönüşmez.

network_proxy varsayılan olarak kapalıdır. Etkinleştirdiğinizde:

Başlatılan komutlara tam ağ erişimi vermeden web arama aracını da denetleyebilirsiniz. Codex, sonuçlara erişmek için varsayılan olarak web arama önbelleğini kullanır. Önbellek, OpenAI tarafından tutulan bir web sonuçları dizinidir; bu nedenle önbellekli mod, canlı sayfaları getirmek yerine önceden dizine eklenmiş sonuçları döndürür. Bu yaklaşım, rastgele canlı içeriklerden gelebilecek istem enjeksiyonuna maruz kalma riskini azaltır ancak web sonuçlarını yine de güvenilmeyen içerik olarak değerlendirmelisiniz. --yolo veya başka bir tam erişimli korumalı alan ayarı kullanıyorsanız web araması varsayılan olarak canlı sonuçları kullanır. Canlı gezinmeye izin vermek için --search kullanın veya web_search = "live" değerini ayarlayın; aracı kapatmak içinse "disabled" olarak ayarlayın:

web_search = "cached"  # default
# web_search = "disabled"
# web_search = "live"  # same as --search

Harici web erişiminin arama diziniyle sınırlandırılması gerektiğinde web_search = "indexed" değerini ayarlayın. Codex'te ağ erişimini veya web aramasını etkinleştirirken dikkatli olun. İstem enjeksiyonu, ajanın güvenilmeyen talimatları getirip izlemesine neden olabilir.

Varsayılanlar ve öneriler

• Codex başlatıldığında klasörün sürüm denetimi altında olup olmadığını algılar ve şunları önerir:
  • Sürüm denetimli klasörler: Auto (çalışma alanına yazma + istek üzerine onaylar)
  • Sürüm denetimsiz klasörler: read-only
• Kurulumunuza bağlı olarak Codex, çalışma dizinine açıkça güvenene kadar (örneğin bir ilk katılım istemi veya /permissions aracılığıyla) read-only modunda da başlayabilir.
• Çalışma alanı, geçerli dizini ve /tmp gibi geçici dizinleri içerir. Çalışma alanında hangi dizinlerin bulunduğunu görmek için /status komutunu kullanın.
• Varsayılanları kabul etmek için codex çalıştırın.
• Bunları açıkça ayarlayabilirsiniz:
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

Yazılabilir köklerdeki korumalı yollar

Varsayılan workspace-write korumalı alan politikasında, yazılabilir kökler yine de korumalı yollar içerir:

• <writable_root>/.git, dizin veya dosya olarak görünmesine bakılmaksızın salt okunur biçimde korunur.
• <writable_root>/.git bir işaretçi dosyasıysa (gitdir: ...), çözümlenen Git dizini yolu da salt okunur biçimde korunur.
• <writable_root>/.agents bir dizin olarak mevcutsa salt okunur biçimde korunur.
• <writable_root>/.codex bir dizin olarak mevcutsa salt okunur biçimde korunur.
• Koruma özyinelemelidir; dolayısıyla bu yolların altındaki her şey salt okunurdur.

Onay istemleri olmadan çalıştırma

Onay istemlerini --ask-for-approval never veya -a never (kısaltma) ile devre dışı bırakabilirsiniz.

Bu seçenek tüm --sandbox modlarıyla çalışır; böylece Codex'in özerklik düzeyini denetlemeye devam edersiniz. Codex, belirlediğiniz kısıtlar içinde elinden geleni yapar.

Codex'in onay istemleri olmadan dosyaları okuması, düzenleme yapması ve ağ erişimiyle komut çalıştırması gerekiyorsa --sandbox danger-full-access (veya --dangerously-bypass-approvals-and-sandbox bayrağı) kullanın. Bunu yapmadan önce dikkatli olun.

Orta yol olarak approval_policy = { granular = { ... } }, belirli onay istemi kategorilerini etkileşimli tutarken diğerlerini otomatik olarak reddetmenize olanak tanır. Ayrıntılı politika; korumalı alan onaylarını, execpolicy kuralı istemlerini, MCP istemlerini, request_permissions istemlerini ve beceri betiği onaylarını kapsar.

Otomatik onay incelemeleri

Onay istekleri varsayılan olarak size yönlendirilir:

approvals_reviewer = "user"

Otomatik onay incelemeleri, approval_policy = "on-request" veya ayrıntılı bir onay politikası gibi onayların etkileşimli olduğu durumlarda uygulanır. Uygun onay isteklerini Codex isteği çalıştırmadan önce bir inceleyici ajana yönlendirmek için approvals_reviewer = "auto_review" değerini ayarlayın:

approval_policy = "on-request"
approvals_reviewer = "auto_review"

İnceleyicinin tüm yaşam döngüsü, tetikleme koşulları, yapılandırma önceliği ve hata davranışı için Otomatik inceleme sayfasına bakın.

İnceleyici yalnızca korumalı alan yükseltmeleri, engellenen ağ istekleri, request_permissions istemleri veya yan etkili uygulama ve MCP aracı çağrıları gibi zaten onay gerektiren işlemleri değerlendirir. Korumalı alan içinde kalan işlemler ek bir inceleme adımı olmadan devam eder.

İnceleyici politikası veri sızdırma, kimlik bilgisi yoklama, kalıcı güvenlik zayıflatma ve yıkıcı işlemleri denetler. Politika izin verdiğinde düşük ve orta riskli işlemler devam edebilir. Politika kritik riskli işlemleri reddeder. Yüksek riskli işlemler yeterli kullanıcı yetkilendirmesi ve eşleşen bir ret kuralının bulunmamasını gerektirir. İstem oluşturma, inceleme oturumu ve ayrıştırma hataları güvenli biçimde reddedilir. Zaman aşımları ayrı olarak gösterilir ancak işlem yine de çalıştırılmaz.

Varsayılan inceleyici politikası, açık kaynaklı Codex deposundadır. Kuruluşlar, yönetilen gereksinimlerde kiracıya özgü bölümünü guardian_policy_config ile değiştirebilir. Yerel [auto_review].policy metni de desteklenir ancak yönetilen gereksinimler önceliklidir. Kurulum ayrıntıları için Yönetilen yapılandırma sayfasına bakın.

ChatGPT masaüstü uygulamasında bu incelemeler; İnceleniyor, Onaylandı, Reddedildi, İptal Edildi veya Zaman Aşımına Uğradı gibi durumlara sahip otomatik inceleme öğeleri olarak görünür. İncelenen istek için risk düzeyi ve kullanıcı yetkilendirmesi değerlendirmesi de içerebilirler.

Otomatik inceleme ek model çağrıları kullandığından Codex kullanımını artırabilir. Yöneticiler bunu allowed_approvals_reviewers ile sınırlandırabilir.

Yaygın korumalı alan ve onay birleşimleri

Etkileşimsiz çalıştırmalar için codex exec --sandbox workspace-write kullanın; Codex eski codex exec --full-auto çağrılarını kullanımdan kaldırılmış bir uyumluluk yolu olarak desteklemeye devam eder ve uyarı yazdırır.

--ask-for-approval untrusted ile Codex yalnızca güvenli olduğu bilinen okuma işlemlerini otomatik olarak çalıştırır. Durumu değiştirebilen veya harici yürütme yollarını tetikleyebilen komutlar (örneğin yıkıcı Git işlemleri ya da Git çıktı/yapılandırma geçersiz kılma bayrakları) onay gerektirir.

config.toml içinde yapılandırma

Daha kapsamlı yapılandırma iş akışı için Temel yapılandırma, Gelişmiş Yapılandırma ve Yapılandırma Referansı sayfalarına bakın.

# Always ask for approval mode
approval_policy = "untrusted"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

# Optional: Allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

# Optional: granular approval policy
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

Ön ayarları profil dosyaları olarak da kaydedebilir, ardından codex --profile profile-name ile seçebilirsiniz:

# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

Korumalı alanı yerel olarak test etme

Bir komut Codex korumalı alanında çalıştırıldığında ne olduğunu görmek için şu Codex CLI komutlarını kullanın:

# macOS
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
# Linux
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
# Windows
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

sandbox komutu codex debug olarak da kullanılabilir ve platform yardımcılarının da diğer adları vardır (örneğin codex sandbox seatbelt ve codex sandbox landlock).

İşletim sistemi düzeyinde korumalı alan

Codex, işletim sisteminize bağlı olarak korumalı alanı farklı biçimlerde uygular:

• macOS, Seatbelt politikalarını kullanır ve komutları seçtiğiniz --sandbox moduna karşılık gelen bir profille (-p) sandbox-exec kullanarak çalıştırır. Kısıtlı okuma erişimi platform varsayılanlarını etkinleştirdiğinde Codex, yaygın araç uyumluluğunu korumak amacıyla /System için geniş kapsamlı izin vermek yerine özenle seçilmiş bir macOS platform politikası ekler.
• Linux varsayılan olarak bwrap ile birlikte seccomp kullanır.
• Windows, Windows Subsystem for Linux 2 (WSL2) üzerinde çalışırken Linux korumalı alanı uygulamasını kullanır. WSL1, Codex 0.114 sürümüne kadar destekleniyordu; 0.115 sürümünden itibaren Linux korumalı alanı bwrap üzerine taşındığından WSL1 artık desteklenmemektedir. Codex, Windows üzerinde yerel olarak çalışırken bir Windows korumalı alanı uygulaması kullanır.

Codex IDE uzantısını Windows'ta kullanıyorsanız uzantı WSL2'yi doğrudan destekler. Ajanı WSL2 kullanılabildiği her durumda WSL2 içinde tutmak için VS Code ayarlarınızda şunu belirleyin:

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

Bu, ana işletim sistemi Windows olsa bile IDE uzantısının komutlar, onaylar ve dosya sistemi erişimi için Linux korumalı alanı semantiğini devralmasını sağlar. Ayrıntılı bilgi için WSL kılavuzuna bakın.

Windows üzerinde yerel olarak çalışırken yerel korumalı alan modunu config.toml içinde yapılandırın:

[windows]
sandbox = "unelevated" # or "elevated"
# sandbox_private_desktop = true  # default; set false only for compatibility

Ayrıntılar için Windows kurulum kılavuzuna bakın.

Linux'u Docker gibi kapsayıcılı bir ortamda çalıştırdığınızda ana makine veya kapsayıcı yapılandırması Codex'in ihtiyaç duyduğu ad alanını, setuid bwrap işlemini ya da seccomp işlemlerini engelliyorsa korumalı alan çalışmayabilir.

Bu durumda Docker kapsayıcınızı ihtiyaç duyduğunuz yalıtımı sağlayacak şekilde yapılandırın, ardından kapsayıcı içinde codex komutunu --sandbox danger-full-access (veya --dangerously-bypass-approvals-and-sandbox bayrağı) ile çalıştırın.

Codex'i Dev Containers içinde çalıştırma

Ana makineniz Linux korumalı alanını doğrudan çalıştıramıyorsa veya kuruluşunuz kapsayıcılı geliştirmeyi zaten standartlaştırmışsa Codex'i Dev Containers ile çalıştırın ve dış yalıtım sınırını Docker'ın sağlamasına izin verin. Bu yaklaşım Visual Studio Code Dev Containers ve uyumlu araçlarla çalışır.

Referans uygulama olarak Codex güvenli devcontainer örneğini kullanın. Örnek; Codex'i, yaygın geliştirme araçlarını, bubblewrap bileşenini ve güvenlik duvarına dayalı giden trafik denetimlerini yükler.

Referans uygulama şunları içerir:

• Codex ve yaygın geliştirme araçlarının yüklü olduğu bir Ubuntu 24.04 temel imajı;
• giden erişim için izin listesiyle yönetilen bir güvenlik duvarı profili;
• çalışma alanını bir kapsayıcıda yeniden açmaya yönelik VS Code ayarları ve uzantı önerileri;
• komut geçmişi ve Codex yapılandırması için kalıcı bağlamalar;
• kapsayıcı gerekli yetenekleri verdiğinde Codex'in Linux korumalı alanını kullanmaya devam edebilmesi için bubblewrap.

Denemek için:

1. Visual Studio Code'u ve Dev Containers uzantısını yükleyin.
2. Codex örneğindeki .devcontainer kurulumunu deponuza kopyalayın veya doğrudan Codex deposundan başlayın.
3. VS Code'da Dev Containers: Open Folder in Container... komutunu çalıştırın ve .devcontainer/devcontainer.secure.json seçeneğini belirleyin.
4. Kapsayıcı başladıktan sonra bir terminal açın ve codex çalıştırın.

Kapsayıcıyı CLI üzerinden de başlatabilirsiniz:

devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

Örneğin üç ana bölümü vardır:

• .devcontainer/devcontainer.secure.json; kapsayıcı ayarlarını, yeteneklerini, bağlamaları, ortam değişkenlerini ve VS Code uzantılarını denetler.
• .devcontainer/Dockerfile.secure, Ubuntu tabanlı imajı ve yüklü araçları tanımlar.
• .devcontainer/init-firewall.sh, giden ağ politikasını uygular.

Referans güvenlik duvarı bilinçli olarak bir başlangıç noktasıdır. Yalıtım için etki alanı izin listesine güveniyorsanız TTL duyarlı yenilemeler veya DNS duyarlı bir güvenlik duvarı gibi ortamınıza uygun DNS yeniden bağlama ve DNS yenileme korumaları uygulayın.

Kapsayıcı içinde şu modlardan birini seçin:

• Dev Container profili, bwrap bileşeninin iç korumalı alanı oluşturması için gereken yetenekleri veriyorsa Codex'in Linux korumalı alanını etkin bırakın.
• Amaçlanan güvenlik sınırınız kapsayıcıysa Codex'in ikinci bir korumalı alan katmanı oluşturmaya çalışmaması için Codex'i kapsayıcı içinde --sandbox danger-full-access ile çalıştırın.

Sürüm denetimi

Codex en iyi şekilde bir sürüm denetimi iş akışıyla çalışır:

• Bir özellik dalında çalışın ve görev vermeden önce git status durumunu temiz tutun. Bu, Codex yamalarının yalıtılmasını ve geri alınmasını kolaylaştırır.
• İzlenen dosyaları doğrudan düzenlemek yerine yama tabanlı iş akışlarını (örneğin git diff/git apply) tercih edin. Küçük artışlarla geri dönebilmek için sık sık commit oluşturun.
• Codex önerilerini diğer tüm PR'lar gibi ele alın: hedefli doğrulamalar çalıştırın, farkları inceleyin ve denetim amacıyla kararları commit iletilerinde belgeleyin.

İzleme ve telemetri

Codex, ekiplerin yerel güvenlik varsayılanlarını zayıflatmadan kullanımı denetlemesine, sorunları araştırmasına ve uyumluluk gereksinimlerini karşılamasına yardımcı olmak için OpenTelemetry (OTel) üzerinden isteğe bağlı izlemeyi destekler. Telemetri varsayılan olarak kapalıdır; yapılandırmanızda açıkça etkinleştirin.

Genel bakış

• Codex, yerel çalıştırmaları kendi içinde tutmak için OTel dışa aktarımını varsayılan olarak kapatır.
• Codex etkinleştirildiğinde sohbetleri, API isteklerini, SSE/WebSocket akışı etkinliğini, kullanıcı istemlerini (varsayılan olarak sansürlenir), araç onayı kararlarını ve araç sonuçlarını kapsayan yapılandırılmış günlük olayları yayınlar.
• Codex, geliştirme/hazırlama/üretim trafiğini ayırmak için dışa aktarılan olayları service.name (başlatan), CLI sürümü ve ortam etiketiyle işaretler.

OTel'i etkinleştirme (isteğe bağlı)

Codex yapılandırmanıza (genellikle ~/.codex/config.toml) bir [otel] bloğu ekleyerek bir dışa aktarıcı seçin ve istem metninin günlüğe kaydedilip kaydedilmeyeceğini belirleyin.

[otel]
environment = "staging"   # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false     # redact prompt text unless policy allows

• exporter = "none", enstrümantasyonu etkin bırakır ancak hiçbir yere veri göndermez.
• Olayları kendi toplayıcınıza göndermek için şunlardan birini seçin:

[otel]
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://otel.example.com:4317",
  headers = { "x-otlp-meta" = "abc123" }
}}

Codex olayları toplu işler ve kapanırken aktarır. Codex yalnızca kendi OTel modülünün ürettiği telemetriyi dışa aktarır.

Olay kategorileri

Temsili olay türleri şunları içerir:

• codex.conversation_starts (model, akıl yürütme ayarları, korumalı alan/onay politikası)
• codex.api_request (deneme, durum/başarı, süre ve hata ayrıntıları)
• codex.sse_event (akış olayı türü, başarı/başarısızlık, süre ve response.completed üzerindeki token sayıları)
• codex.websocket_request ve codex.websocket_event (istek süresi ve ileti başına tür/başarı/hata)
• codex.user_prompt (uzunluk; açıkça etkinleştirilmedikçe içerik sansürlenir)
• codex.tool_decision (onaylandı/reddedildi, kaynak: yapılandırma veya kullanıcı)
• codex.tool_result (süre, başarı, çıktı parçacığı)

İlişkili OTel metrikleri (sayaç ve süre histogramı çiftleri) codex.api_request, codex.sse_event, codex.websocket.request, codex.websocket.event ve codex.tool.call (karşılık gelen .duration_ms araçlarıyla) metriklerini içerir.

Tüm olay kataloğu ve yapılandırma referansı için GitHub'daki Codex yapılandırma belgelerine bakın.

Güvenlik ve gizlilik rehberi

• Politikanız istem içeriklerinin saklanmasına açıkça izin vermediği sürece log_user_prompt = false ayarını koruyun. İstemler kaynak kodu ve hassas veriler içerebilir.
• Telemetriyi yalnızca denetiminizdeki toplayıcılara yönlendirin; uyumluluk gereksinimlerinize uygun saklama sınırları ve erişim denetimleri uygulayın.
• Araç bağımsız değişkenlerini ve çıktılarını hassas olarak değerlendirin. Mümkün olduğunda toplayıcıda veya SIEM'de sansürlemeyi tercih edin.
• Codex'in oturum dökümlerini CODEX_HOME altında kaydetmesini istemiyorsanız yerel veri saklama ayarlarını (örneğin history.persistence / history.max_bytes) gözden geçirin. Gelişmiş Yapılandırma ve Yapılandırma Referansı sayfalarına bakın.
• CLI'ı ağ erişimi kapalı şekilde çalıştırırsanız OTel dışa aktarımı toplayıcınıza erişemez. Dışa aktarmak için OTel uç noktası adına workspace-write modunda ağ erişimine izin verin veya Codex cloud üzerinden, toplayıcı etki alanı onaylı listenizde olacak şekilde dışa aktarın.
• Onay/korumalı alan değişikliklerini ve beklenmeyen araç yürütmelerini tespit etmek için olayları düzenli olarak inceleyin.

OTel isteğe bağlıdır ve yukarıda açıklanan korumalı alan ile onay korumalarının yerini almak için değil, onları tamamlamak için tasarlanmıştır.

Yönetilen yapılandırma

Kurumsal yöneticiler, çalışma alanlarına yönelik Codex güvenlik ayarlarını Yönetilen yapılandırma bölümünde yapılandırabilir. Kurulum ve politika ayrıntıları için bu sayfaya bakın.