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 ortamda, dokunabileceği öğeleri (genellikle mevcut çalışma alanıyla) sınırlayan işletim sistemi tarafından uygulanan bir korumalı alanın yanı sıra, eyleme geçmeden önce ne zaman durup sizden izin istemesi gerektiğini denetleyen 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.

Kullanımdan kaldırılan untrusted onay ilkesinden geçiş

Codex ve ChatGPT Work artık approval_policy = "untrusted" ayarını desteklemiyor. Kullanımdan kaldırılan bu ayar, her iki istemcinin de başlamasını engelleyebilir. Ayarı kullanıcı veya proje yapılandırmasından, profil dosyalarından, başlangıç betiklerinden ve yönetilen varsayılanlardan kaldırın. Etkileşimli, salt okunur kullanım için:

sandbox_mode = "read-only"
approval_policy = "on-request"

Alternatif olarak codex --sandbox read-only --ask-for-approval on-request komutunu çalıştırın.

on-request ile korumalı alanın izin verdiği komutlar onay olmadan çalışabilir, erişilebilir dosyaları okuyabilir ve etkinleştirilmişse ağ erişimini kullanabilir.

Daha katı komut onayı kuralını korumak için açıkça bir approval_policy ayarı belirtmeyin ve kullanıcı düzeyindeki şu dosyanıza bir proje kaydı ekleyin: ~/.codex/config.toml:

[projects."/path/to/project"]
trust_level = "untrusted"

Böylece bir yürütme ilkesi kuralı izin vermediği sürece komutlar onay gerektirir. Bu, projeye yerel yapılandırmayı da devre dışı bırakır. on-request ayarının açıkça belirtilmesi, projeden türetilen ilkeyi geçersiz kılar; yönetilen allowed_approval_policies ayarı, buna izin vermek için untrusted değerini içermelidir.

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 yapabilecekleri (örneğin nereye yazabileceği ve ağa erişip erişemeyeceği).
• Onay politikası: Codex'in bir eylemi yürütmeden önce ne zaman size sorması gerektiği (örneğin korumalı alanın dışına çıkma, ağı kullanma veya güvenilir bir kümenin dışındaki komutları çalıştırma).

Codex, çalıştırıldığı yere 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şilmesini önler. İ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ı, ilgili ortam için internet erişimini etkinleştirmediğiniz sürece varsayılan olarak çevrimdışı çalışır. Cloud 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ı: İşletim sistemi düzeyindeki mekanizmalar korumalı alan politikalarını uygular. Varsayılan ayarlar arasında ağ erişiminin olmaması ve yazma izinlerinin etkin çalışma alanıyla sınırlanması 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üzenlemeler yapabilir 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, eylem 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 de onay isteyebilir. Yıkıcı uygulama/MCP aracı çağrıları, araç yıkıcı ek açıklama bildirdiğinde her zaman onay gerektirir (araç öncelikli olan bir okuma ek açıklaması bildirmediği sürece).

Güvenlik izleme ve duraklatılan görevler

GPT-6 Astra, Codex ve ChatGPT Work'te güvenlik izleme özelliğini içerir. İzleme eşzamansız olarak çalışır ve güvenli olmayabilecek bir model davranışı algılarsa görevi duraklatabilir. Duraklatma, bunu tetikleyen etkinlikten sonra gerçekleşebilir; izleme, korumalı alanın, izinlerin veya sonucun incelenmesinin yerini tutmaz.

Bir görev duraklatılırsa bildirimi okuyun ve bulgular sunulduğunda bunları inceleyin. Yalnızca görevin güvenle devam edebileceğini kontrol ettikten sonra sürdürün. Bildirimde görevin sona erdiği belirtiliyorsa veya sürdürme seçeneği sunulmuyorsa görevi o arayüzden sürdüremezsiniz.

Güvenlik izleme, görev sırasında model davranışını değerlendirir. Otomatik onay incelemesi, söz konusu eylemler çalıştırılmadan önce zaten onay gerektiren bağımsız eylemleri değerlendirir. Otomatik onay incelemesinin onayladığı bir eylem, izlemenin daha sonra duraklattığı bir görevin yine de parçası olabilir.

Ağ erişimi

Codex cloud için tam internet erişimini veya 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. Komut 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. Etki alanı kuralları eklemek proxy'yi kendiliğinden etkinleştirmez.

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

Tek seferlik bir CLI oturumunda yalnızca açma/kapatma ayarına ihtiyacınız varsa Boolean 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 vermez. 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.

Proxy özelliği izin profillerine de uygulanır. Bir profilin network.enabled = true ayarı komut ağı erişimi verirken features.network_proxy = true, o profilin etki alanı kurallarının uygulanmasını etkinleştirir:

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

Bu örnekte proxy özelliğini atlarsanız komutlar doğrudan ağ erişimine sahip olur ve api.openai.com izin kuralı hedeflerini kısıtlamaz.

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

Ağ politikası

Etki alanı kuralları önce izin listesi ilkesini izler:

• Tam ana bilgisayar 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 bilgisayarlarla eşleşir. * ayarını geniş ağ erişimi olarak değerlendirin ve mümkün olduğunda kapsamı belirli kuralları tercih edin.
• deny her zaman allow üzerinde ö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 komutun tek bir yerel hedefe ihtiyacı olduğunda tam bir yerel IP değişmezini veya localhost izin kuralını ekleyin.
• Daha geniş erişim: Yalnızca daha geniş yerel/özel erişimi bilerek istediğinizde allow_local_binding = true ayarını yapı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 bilgisayar adları engellenmeye devam eder.

DNS yeniden bağlama korumaları

Codex, bir ana bilgisayar adına izin vermeden önce en iyi çabaya dayalı bir DNS ve IP sınıflandırma denetimi gerçekleştirir:

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

Tehdit modeliniz kötü niyetli DNS'i kapsıyorsa çıkış 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ı biçimde denetlenen ortamlarda kullanın. Unix soketi proxy'leme 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:

Komut ağı proxy'sinin dışındaki trafik

Ağ proxy'si, yerel komut korumalı alanında çalışan betikleri, programları ve alt süreçleri filtreler. Web aramasını, uygulama veya bağlayıcı aracı çağrılarını, MCP sunucusu bağlantılarını, tarayıcı veya Computer Use etkinliklerini, Codex cloud görevlerini ya da istemcinin model ve kimlik doğrulama isteklerini filtrelemez. Bu yüzeyler ayrı hizmet bağlantıları, özellik ayarları, çalışma alanı politikaları veya ortam denetimleri kullanır.

Tarayıcı araçları, bir kaynağa erişmeden önce yönetilen ağ engelleme kurallarını ve özel izin listelerini ayrıca denetler. Tarayıcı kaynak politikaları siteye erişimi, yüklemeleri, indirmeleri ve geliştirici araçlarını daha da kısıtlayabilir. Bkz. yönetilen tarayıcı denetimleri.

Yönetilen kullanıcılar için komut ağı politikasını allowed_web_search_modes, onaylanmış mcp_servers ve uygulamalar, eklentiler, tarayıcılar veya Computer Use için özellik gereksinimleri gibi denetimlerle birleştirin. Yönetilen yapılandırma sayfasına bakın.

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 bir web arama önbelleği kullanır. Önbellek, OpenAI tarafından yönetilen bir web sonuçları dizinidir; dolayısıyla önbelleğe alınmış mod, canlı sayfaları getirmek yerine önceden dizine eklenmiş sonuçları döndürür. Bu, rastgele canlı içerikten gelebilecek istem enjeksiyonu saldırılarına maruz kalmayı 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" ayarını yapı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" ayarını yapı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 denetiminde 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 denetimi olmayan klasörler: read-only
• Kurulumunuza bağlı olarak, çalışma dizinine açıkça güvenene kadar (örneğin bir ilk kullanım istemi veya /permissions aracılığıyla) Codex read-only modunda da başlayabilir.
• Çalışma alanı, mevcut dizini ve /tmp gibi geçici dizinleri içerir. Çalışma alanındaki dizinleri görmek için /status komutunu kullanın.
• Varsayılanları kabul etmek için codex komutunu ç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ünmesinden bağımsız olarak 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; dolayısıyla Codex'in özerklik düzeyini yine siz denetlersiniz. Codex, belirlediğiniz kısıtlar içinde elinden geleni yapar.

Codex'in onay istemleri olmadan dosyaları okuması, düzenlemeler yapması ve ağ erişimiyle komutlar ç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-rule istemlerini, MCP istemlerini, request_permissions istemlerini ve beceri betiği onaylarını kapsar.

Otomatik onay incelemeleri

Varsayılan olarak onay istekleri 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" ayarını yapın:

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

İnceleyicinin tam 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 yetki yükseltmeleri, engellenmiş ağ istekleri, request_permissions istemleri veya yan etkili uygulama ve MCP aracı çağrıları gibi zaten onay gerektiren eylemleri değerlendirir. Korumalı alan içinde kalan eylemler 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ı eylemleri denetler. Politika izin verdiğinde düşük ve orta riskli eylemler devam edebilir. Politika kritik riskli eylemleri reddeder. Yüksek riskli eylemler, 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 başarısız olur. Zaman aşımları ayrı olarak gösterilir ancak eylem yine de çalıştırılmaz.

Varsayılan inceleyici politikası, açık kaynaklı Codex deposundadır. Kuruluşlar, kiracıya özgü bölümünü yönetilen gereksinimlerde 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ım dışı bırakılmış uyumluluk yolu olarak tutar ve bir uyarı gösterir.

config.toml içinde yapılandırma

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

# Interactive approvals with a read-only sandbox
approval_policy = "on-request"
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ığı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 takma 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çimde uygular:

• macOS, Seatbelt politikalarını kullanır ve seçtiğiniz --sandbox moduna karşılık gelen bir profille (-p) sandbox-exec kullanarak komutları çalıştırır. Kısıtlı okuma erişimi platform varsayılanlarını etkinleştirdiğinde Codex, yaygın araç uyumluluğunu korumak için /System konumuna geniş ölçüde izin vermek yerine özenle seçilmiş bir macOS platform politikası ekler.
• Linux varsayılan olarak bwrap ve seccomp kullanır.
• Windows, Windows Subsystem for Linux 2 (WSL2) içinde ç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 başlayarak Linux korumalı alanı bwrap konumuna 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. Kullanılabilir olduğunda ajanı WSL2 içinde tutmak için VS Code ayarlarınızda şunu ayarlayın:

{
  "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ı anlamını devralmasını sağlar. WSL kılavuzundan daha fazla bilgi edinin.

Windows'ta 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 sistem veya kapsayıcı yapılandırması, Codex'in ihtiyaç duyduğu ad alanını, setuid bwrap 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 biçimde 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 sisteminiz Linux korumalı alanını doğrudan çalıştıramıyorsa veya kuruluşunuz kapsayıcılı geliştirmeyi zaten standartlaştırdıysa 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, Visual Studio Code Dev Containers ve uyumlu araçlarla çalışır.

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

Başvuru uygulaması şunları içerir:

• Codex ve yaygın geliştirme araçlarının yüklü olduğu Ubuntu 24.04 tabanlı bir imaj;
• giden erişim için izin listesine dayalı 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 öğesini seçin.
4. Kapsayıcı başladıktan sonra bir terminal açın ve codex komutunu çalıştırın.

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

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

Örnek üç ana parçadan oluşur:

• .devcontainer/devcontainer.secure.json kapsayıcı ayarlarını, yetenekleri, 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.

Başvuru 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ının içinde şu modlardan birini seçin:

• Dev Container profili, bwrap öğesinin iç korumalı alanı oluşturması için gereken yetenekleri veriyorsa Codex'in Linux korumalı alanını etkin tutun.
• 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, bir sürüm denetimi iş akışıyla en iyi şekilde çalışır:

• Bir özellik dalında çalışın ve görev devretmeden önce git status öğesini 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 adımlarla geri dönebilmek için sık sık commit oluşturun.
• Codex önerilerini diğer PR'lar gibi ele alın: Hedefli doğrulama çalıştırın, diff'leri inceleyin ve denetim amacıyla kararları commit mesajlarında 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ı bağımsız tutmak için OTel dışa aktarımını varsayılan olarak kapatır.
• Etkinleştirildiğinde Codex; sohbetleri, API isteklerini, SSE/WebSocket akışı etkinliğini, kullanıcı istemlerini (varsayılan olarak maskelenir), araç onayı kararlarını ve araç sonuçlarını kapsayan yapılandırılmış günlük olayları yayınlar.
• Codex, geliştirme/hazırlık/üretim trafiğini ayırmak için dışa aktarılan olayları service.name (başlatan), CLI sürümü ve bir 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 ekleyin; bir dışa aktarıcı ve istem metninin günlüğe kaydedilip kaydedilmeyeceğini seçin.

[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" ölçümlemeyi etkin bırakır ancak verileri hiçbir yere 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ü tarafından üretilen telemetriyi dışa aktarır.

Olay kategorileri

Temsilî olay türleri şunlardır:

• 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üresinin yanı sıra ileti başına tür/başarı/hata)
• codex.user_prompt (uzunluk; açıkça etkinleştirilmediği sürece içerik maskelenir)
• 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) arasında 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) bulunur.

Tam olay kataloğu ve yapılandırma başvurusu için GitHub'daki Codex yapılandırma belgelerine bakın.

Güvenlik ve gizlilik rehberi

• Politika 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 denetlediğiniz toplayıcılara yönlendirin; uyumluluk gereksinimlerinizle uyumlu saklama sınırları ve erişim denetimleri uygulayın.
• Araç bağımsız değişkenlerini ve çıktılarını hassas kabul edin. Mümkün olduğunda toplayıcıda veya SIEM'de maskelemeyi 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) inceleyin. Gelişmiş Yapılandırma ve Yapılandırma Başvurusu sayfalarına bakın.
• CLI'ı ağ erişimi kapalı olarak çalıştırırsanız OTel dışa aktarımı toplayıcınıza ulaşamaz. Dışa aktarmak için OTel uç noktası adına workspace-write modunda ağ erişimine izin verin veya toplayıcı etki alanı onaylanmış listenizde olacak şekilde Codex cloud'dan dışa aktarın.
• Onay/korumalı alan değişiklikleri ve beklenmeyen araç yürütmeleri için olayları düzenli olarak inceleyin.

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

Yönetilen yapılandırma

Kurumsal yöneticiler, çalışma alanlarının 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.