ChatGPT Belgeleri
Türkçe
İletişim goolvyouyou@gmail.com

Yönetilen yapılandırma

Yönetilen yapılandırma

Desteklenen yerel istemcilere yapılandırma varsayılanlarını dağıtın ve gereksinimleri zorunlu kılın

Yönetilen yapılandırma; ChatGPT masaüstü uygulaması, Codex CLI ve IDE uzantısındaki kapsama alınmış yetenekler için desteklenen yerel çalışma zamanı davranışını denetler. Desteklenen gereksinimler istemciye ve sürüme göre farklılık gösterebilir. Yönetilen yapılandırma, ChatGPT çalışma alanına erişim sağlamaz, lisans atamaz veya çalışma alanının rol tabanlı erişim denetiminin (RBAC) yerini almaz. Çalışma alanı özelliklerine erişim için Roller ve çalışma alanı izinleri sayfasını, yerel çalışma zamanı politikası için bu sayfayı kullanın.

Kurumsal yöneticiler, desteklenen yerel istemci davranışlarını şu yollarla denetleyebilir:

  • Gereksinimler: yöneticilerin zorunlu kıldığı ve kullanıcıların geçersiz kılamadığı kısıtlamalar.
  • Yapılandırma varsayılanları: sistem veya bulut tarafından yönetilen, kullanıcıların geçersiz kılabildiği config.toml ayarları.
  • Eski yönetilen varsayılanlar: desteklenen bir istemci başlatıldığında uygulanan managed_config.toml başlangıç değerleri. Kullanıcılar çalışma sırasında ayarları değiştirebilir; istemci bir sonraki başlatılışında bu varsayılanları yeniden uygular.

Eklenti pazar yerlerini ve varsayılanları yapılandırın

Yerel veya Git pazar yerlerini ve eklenti varsayılanlarını sistemdeki config.toml dosyasında veya Yönetilen yapılandırma sayfasının config.toml bölümünde tanımlayın. Bu ayarlar varsayılan değerlerdir, zorunlu kılınan politikalar değildir.

Yapılandırma anahtarları için Yapılandırma Referansı, Yapılandırma önceliği bölümüne geçersiz kılmalar için ve depo eklenti ayarları bölümüne proje düzeyindeki yapılandırma için bakın. Çalışma alanına GitHub'dan içe aktarma ve senkronizasyon ayrı bir konudur.

Yönetici tarafından zorunlu kılınan gereksinimler (requirements.toml)

Gereksinimler, güvenlik açısından hassas ayarları (onay politikası, onayları inceleyen taraf, otomatik inceleme politikası, korumalı alan modu, izin profilleri, web arama modu, yönetilen kancalar, kullanıcıların hangi MCP sunucularını etkinleştirebileceği ve hangi eklenti pazar yeri kaynaklarını kullanabileceği) kısıtlar. Yapılandırma çözümlenirken (örneğin config.toml, profil dosyaları veya CLI yapılandırma geçersiz kılmalarından), bir değer zorunlu kılınan bir kuralla çelişirse yerel istemci uyumlu bir değere döner ve kullanıcıyı bilgilendirir. Bir mcp_servers izin listesi yapılandırırsanız istemci, bir MCP sunucusunu yalnızca hem adı hem de kimliği onaylanmış bir kayıtla eşleştiğinde etkinleştirir; aksi takdirde devre dışı bırakır.

Gereksinimler, requirements.toml içindeki [features] tablosu aracılığıyla özellik bayraklarını da kısıtlayabilir. Özelliklerin her zaman güvenlik açısından hassas olmadığını, ancak kuruluşların isterse değerleri sabitleyebileceğini unutmayın. Atlanan anahtarlar kısıtlanmadan kalır.

Codex 0.138.0 veya sonraki sürümlerde allowed_permission_profiles ve yönetilen default_permissions ile izin profillerini tercih edin. allowed_sandbox_modes öğesini yalnızca hâlâ sandbox_mode yapılandıran eski dağıtımlar için kullanın.

Tam anahtar listesi için Yapılandırma Referansı'ndaki requirements.toml bölümüne bakın.

Kullanımdan kaldırılan untrusted onay politikasından geçiş yapın

Codex ve ChatGPT Work artık approval_policy = "untrusted" ayarını desteklemiyor. Bu ayarı yönetilen varsayılanlardan, eski managed_config.toml dosyasından ve ayarın tanımlandığı tüm kullanıcı, proje, profil veya başlangıç yapılandırmalarından kaldırın.

Etkileşimli, salt okunur kullanım için approval_policy = "on-request" ayarını, yönetilen gereksinimlerinizin izin verdiği salt okunur bir korumalı alan veya izin profiliyle birlikte seçin. Bu korumalı alanın izin verdiği komutlar onay alınmadan çalıştırılabilir.

Daha katı komut onaylarını korumak için açık bir approval_policy ayarı belirtmeyin; trust_level = "untrusted" ayarını, kullanıcı düzeyindeki proje kaydında, ~/.codex/config.toml içinde tanımlayın ve untrusted değerini allowed_approval_policies içinde tutun. Bu, projeye yerel yapılandırmayı da devre dışı bırakır. on-request ayarını açıkça belirtmek bu ilkeyi geçersiz kılar. Örnekler ve güvenlik açısından ödünleşimler için Kullanımdan kaldırılan untrusted onay ilkesinden geçiş bölümüne bakın.

Konumlar ve öncelik

Desteklenen her yerel istemci, gereksinimleri düşük öncelikten yüksek önceliğe doğru birleştirir:

  1. Sistem requirements.toml (Linux ve macOS dâhil Unix sistemlerinde /etc/codex/requirements.toml veya Windows'ta %ProgramData%\OpenAI\Codex\requirements.toml).
  2. Bulut yapılandırma paketinde sunulan, kuruluş tarafından yönetilen gereksinimler.
  3. Yerel istemcinin gereksinimler olarak yeniden yorumladığı eski managed_config.toml alanları.
  4. com.openai.codex:requirements_toml_base64 üzerinden sunulan macOS yönetilen tercihleri (MDM).

Daha yüksek öncelikli katmanlar, daha düşük öncelikli katmanlardaki sıradan skaler ve liste değerlerini geçersiz kılar. Tablolar anahtara göre birleştirilirken kurallar, kancalar ve dosya sistemi kısıtlamaları gibi gereksinimler alana özgü birleştirme davranışına sahiptir. Her alanın aynı şekilde birleştirildiğini varsaymak yerine güncel şema için requirements.toml referansını kullanın.

Geriye dönük uyumluluk için desteklenen yerel istemciler eski approval_policy, approvals_reviewer ve sandbox_mode alanlarını gereksinimler olarak yeniden yorumlar. Bu dönüştürme, gerektiğinde uyumluluk seçenekleri ekler; açık izin listeleri için requirements.toml kullanın.

Bulut tarafından yönetilen gereksinimler

Bir kullanıcı desteklenen bir plan kapsamında ChatGPT ile oturum açtığında, desteklenen yerel istemciler çalışma alanıyla ilişkili, yöneticinin zorunlu kıldığı gereksinimleri alabilir. Bu, requirements.toml ile uyumlu ilkeler için bir dağıtım kanalıdır. Çalışma alanına erişim sağlamaz veya çalışma alanının RBAC mekanizmasının yerini almaz. Kimlik doğrulama gereksinimleri yerel olarak yönetilmelidir.

Bulut üzerinden yönetilen gereksinimler oluşturmak ve atamak için Yönetilen yapılandırma sayfasını açın. Örneğin bu politika, onay ve korumalı alan seçeneklerini sınırlar ve desteklenen bir kabuk giriş noktası çalışmadan önce kullanıcıdan onay ister:

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Require explicit approval for shell entry points" },
]

Yönetilen her istemci sürümünün seçtiğiniz anahtarları desteklediğini doğrulayın ve kuruluş genelinde atama yapmadan önce politikayı küçük bir grupla test edin. Güncel şema için yapılandırma referansını, güncel atama davranışı için yönetim arayüzünü kullanın.

Hizmet, oturum açmış kimliğe uygulanan ve kuruluş tarafından yönetilen gereksinim katmanlarını seçer. Yerel istemci bu katmanları, Konumlar ve öncelik bölümünde açıklanan diğer gereksinim kaynaklarıyla birlikte değerlendirir. Çalışma alanı tarafındaki oluşturma ve atama işlemleri için güncel yönetim arayüzünü kullanın. Kopyalanmış bir grup eşleştirme algoritmasına güvenmeyin; bu davranış yönetim hizmetine aittir ve yerel gereksinim biçiminden bağımsız olarak değişebilir.

Desteklenen anahtarlar ve örnekler için Örnek requirements.toml ve requirements.toml referansına bakın.

Yerel istemciler bulut tarafından yönetilen gereksinimleri nasıl uygular?

Bir kullanıcı desteklenen bir yerel istemciyi başlatıp desteklenen bir planda ChatGPT ile oturum açtığında istemci önce kimlikle eşleşen geçerli bir önbellek kaydını denetler. Geçerli bir kayıt yoksa istemci yeniden denemelerle uygulanabilir paketi getirir ve başarılı olduğunda imzalı bir önbellek kaydı yazar. İstek başarısız olur veya zaman aşımına uğrarsa ve geçerli bir önbellek yoksa bulut yapılandırma paketi yüklemesi, bulut tarafından yönetilen gereksinimler katmanı olmadan sessizce başlamak yerine hata döndürür.

Önbellek çözümlemesinden sonra istemci, bulut gereksinimlerini yukarıda açıklanan diğer gereksinim katmanlarıyla birleştirir. Arka planda yenileme, önbelleği sonraki bir başlangıç için güncelleyebilir; geçerli süreçte zaten yüklenmiş gereksinimlerin yerini almaz.

Yönetici ve çalışan deneyimini doğrulayın

Yönetilen her politikanın sorumluluğunu üstlenecek bir kişi atayın, hangi kullanıcıların veya grupların bu politikayı alması gerektiğini kaydedin ve dosya sistemi, ağ, onay ya da izin profili kısıtlamalarının iş gerekçesini belgelendirin.

Kullanıma sunma kapsamını genişletmeden önce onaylı bir iş akışını ve kasıtlı olarak izin verilmeyen bir iş akışını temsili bir kullanıcıyla test edin. Yerel kısıtlamanın yalnızca bir çalışma alanı rolü veya grup tarafından uygulandığını varsaymak yerine, desteklenen istemcideki etkin ayarları doğrulayın.

Kimlik doğrulamayı yerel olarak yönetin

allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store ve chatgpt_base_url ayarlarını yerel sistemdeki requirements.toml dosyasında veya macOS MDM gereksinimlerinde tanımlayın. Codex bu dört alanı buluttan yönetilen gereksinimlerde yok sayar. Yerel kimlik doğrulama gereksinimleri, kimlik bilgileri yüklenmeden ve Codex bulut ilkesini almadan önce uygulanır.

Onaylı bir çalışma alanında ChatGPT ile oturum açmayı zorunlu kılmak ve kimlik bilgilerini işletim sisteminin kimlik bilgisi deposunda saklamak için şunu kullanın:

allowed_login_methods = ["chatgpt"]
allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]
cli_auth_credentials_store = "keyring"

allowed_login_methods, chatgpt, api veya her ikisini kabul eder. Belirtilmezse bu ayar oturum açma yöntemlerini kısıtlamaz. Ayarlanırsa liste en az bir yöntem içermelidir. api, Amazon Bedrock dahil API kimlik doğrulamasına izin verir. Çalışma alanı kısıtlaması Codex erişim belirteçleri için de geçerlidir.

Kullanıcının yapılandırdığı forced_login_method ve forced_chatgpt_workspace_id ayarları gereksinimlere uymalıdır. Kullanıcı bir çalışma alanı seçtiğinde bu alanın da yönetilen çalışma alanı izin listesinde bulunması gerekir. Eşleşen çalışma alanı yoksa ChatGPT ile oturum açma kullanılamaz. İzin verildiğinde API kimlik doğrulaması kullanılabilir olmaya devam eder. Kullanılabilir bir oturum açma yöntemi yoksa Codex başlatılmayı reddeder.

Kimlik bilgisi saklama modları ve hizmet URL yapılandırması için gereksinimler referansına bakın.

Örnek requirements.toml

Bu örnek, --ask-for-approval never ve --sandbox danger-full-access öğelerini (--yolo dâhil) engeller:

allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Burada untrusted, daha katı onay davranışını korur; bu davranışın kaynağı trust_level = "untrusted" ayarıdır. Bu, approval_policy = "untrusted" ayarının açıkça belirtilmesini desteklenen bir seçenek hâline getirmez.

Appshots'u devre dışı bırakma

Yönetilen kullanıcılar için Appshots'u devre dışı bırakmak üzere üst düzey allow_appshots gereksinimini ayarlayın:

allow_appshots = false

Appshots'un kullanılabildiği yerlerde allow_appshots = false bunları devre dışı bırakır. Anahtarı atlarsanız gereksinimler Appshots'u kısıtlamaz ve normal ürün kullanılabilirliği denetimleri uygulanır. Etkin gereksinimleri configRequirements/read üzerinden okuyan uygulama sunucusu istemcileri, allowAppshots ile aynı kısıtlamayı alır; atlanmış veya null olan bir allowAppshots değeri Appshots'u devre dışı bırakmaz.

Cihaz uzaktan denetimini devre dışı bırakma

Yönetilen kullanıcılar için cihaz uzaktan denetimini devre dışı bırakmak üzere üst düzey allow_remote_control gereksinimini ayarlayın:

allow_remote_control = false

Cihaz uzaktan denetiminin desteklendiği yerlerde allow_remote_control = false bunu devre dışı bırakır. Anahtarı atlarsanız gereksinimler cihaz uzaktan denetimini kısıtlamaz ve normal ürün kullanılabilirliği denetimleri uygulanır. Bu gereksinim SSH uzak bağlantılarını devre dışı bırakmaz.

Kullanılabilir izin profillerini denetleme

Kullanıcıların hangi yerleşik ve özel izin profillerini seçebileceğini denetlemek için allowed_permission_profiles kullanın. Bu, allowed_sandbox_modes öğesinin izin profili karşılığıdır; kullanıcılarınızın izin seçme biçimiyle eşleşen izin listesini kullanın.

İzin profili izin listeleri Codex 0.138.0 veya sonraki bir sürümü gerektirir. Codex 0.137.0 ve önceki sürümler allowed_permission_profiles ile yönetilen default_permissions öğesini yok sayar.

Aşağıdaki izin profili örneklerini yalnızca yönetilen her istemci desteklenen bir sürümü çalıştırdıktan sonra kullanın. Filo yükseltmesi tamamlanmadan yönetilen özel profilleri dağıtmayın.

Tablo mevcut olduğunda izin verilen profillerin eksiksiz listesidir. true olarak ayarlanan profillere izin verir; gelecekteki Codex sürümlerinde eklenecek yerleşik profiller dâhil olmak üzere atlanan veya false olarak ayarlanan profilleri reddeder.

Standart profillere izin verme

Bu politika salt okunur erişime ve çalışma alanı erişimine izin verir, ancak tam erişime izin vermez:

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

Yönetilen, en düşük ayrıcalıklı bir varsayılan ekleme

Yöneticiler aynı gereksinim kaynağında özel bir profil tanımlayabilir. Kullanıcıların yüklenen yapılandırmalarındaki adlarla çakışmayacak, kuruluşa özgü profil adları kullanın. Özel adlar : ile başlayamaz veya ayrılmış filesystem adını kullanamaz.

Yönetilen özel profilleri Codex 0.137.0 veya önceki sürümleri çalıştıran istemcilere dağıtmayın. Bu istemciler profil tablosunu tanır, ancak onu seçen yönetilen varsayılanı tanımaz.

Örneğin:

default_permissions = "acme_review_only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
acme_review_only = true
# ":danger-full-access" is intentionally omitted, so it is denied.

[permissions.acme_review_only]
description = "Review code without modifying the workspace."
extends = ":read-only"

Yalnızca kuruluş tarafından tanımlanan profillere izin verme

Kullanıcıların yalnızca yönetici tarafından tanımlanan profilleri seçmesi gerekiyorsa tüm yerleşik profilleri atlayın:

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

[permissions.acme_workspace]
description = "Workspace access with sensitive files denied."
extends = ":workspace"

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

[permissions.acme_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Kullanıcılar yerleşik :workspace profilini doğrudan seçemese bile özel profil :workspace öğesini genişletebilir.

Başka bir kaynağın izin verdiği profili kapatma

İzin listeleri profil adına göre birleştirilir. Bulut gereksinimleri sistem gereksinimlerinden daha yüksek önceliğe sahip olduğundan, sistem dosyasının izin verdiği bir profili kapatmak için bulut gereksinimleri false kullanabilir.

Bulut gereksinimleri:

default_permissions = ":read-only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = false

Sistem gereksinimleri:

[allowed_permission_profiles]
":read-only" = true
":workspace" = true  # Not honored because cloud requirements set this to false.

default_permissions değerini açıkça izin verilen bir profile ayarlayın. Atlanırsa yerel çalışma zamanı yalnızca hem :workspace hem de :read-only açıkça izinli olduğunda varsayılan olarak :workspace kullanır. allowed_permission_profiles yoksa yönetilen gereksinimler kullanıcıların seçebileceği profil adlarını kısıtlamaz. Her kayıt, yerleşik bir profili veya yüklenen bir yapılandırma ya da gereksinim kaynağında tanımlanmış özel bir profili adlandırmalıdır. Davranışlarını merkezi olarak denetlemek için özel profilleri yönetilen gereksinimlerde tanımlayın.

Korumalı alan gereksinimlerini ana makineye göre geçersiz kılma

Tek bir yönetilen politikanın farklı ana makinelerde farklı korumalı alan gereksinimleri uygulaması gerektiğinde [[remote_sandbox_config]] kullanın. Örneğin, eşleşen geliştirme makinelerinde veya CI çalıştırıcılarında çalışma alanına yazmaya izin verirken dizüstü bilgisayarlar için daha katı bir varsayılanı koruyabilirsiniz. Ana makineye özgü kayıtlar şu anda yalnızca allowed_sandbox_modes öğesini geçersiz kılar:

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Yerel çalışma zamanı, her hostname_patterns kaydını mümkün olan en iyi şekilde çözümlenmiş ana makine adıyla karşılaştırır. Kullanılabildiğinde tam nitelikli alan adını tercih eder, aksi takdirde yerel ana makine adını kullanır. Eşleştirme büyük/küçük harfe duyarsızdır; * herhangi bir karakter dizisiyle, ? ise tek bir karakterle eşleşir.

Aynı gereksinim kaynağında eşleşen ilk [[remote_sandbox_config]] kaydı geçerli olur. Hiçbir kayıt eşleşmezse yerel çalışma zamanı üst düzey allowed_sandbox_modes değerini korur. Ana makine adı eşleştirmesi yalnızca politika seçimi içindir; bunu kimliği doğrulanmış cihaz kanıtı olarak değerlendirmeyin.

Web araması modunu da kısıtlayabilirsiniz:

allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowed

allowed_web_search_modes = [] yalnızca "disabled" öğesine izin verir. Örneğin allowed_web_search_modes = ["cached"], danger-full-access oturumlarında bile canlı web aramasını engeller.

Ağ erişimi gereksinimlerini yapılandırma

Yöneticilerin ağ erişimi gereksinimlerini merkezi olarak tanımlaması gerektiğinde requirements.toml içinde [experimental_network] kullanın. Bu gereksinimler, kullanıcıya ait features.network_proxy geçiş düğmesinden ayrıdır: bu özellik bayrağı olmadan korumalı alan ağını yapılandırabilirler ancak etkin korumalı alan ağı kapalı tuttuğunda komutlara ağ erişimi vermezler. Yönetilen proxy'yi etkinleştirmek için experimental_network.enabled = true değerini ayarlayın; yalnızca alan adı kuralları proxy'yi etkinleştirmez.

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"api.openai.com" = "allow"
"**.example.com" = "allow"
"blocked.example.com" = "deny"
"**.exfil.example.com" = "deny"

experimental_network.managed_allowed_domains_only = true seçeneğini yalnızca [experimental_network.domains] içinde yöneticiye ait "allow" girdileri de tanımladığınızda ve bu kuralların özel olmasını istediğinizde kullanın. Yönetilen izin kuralları yokken bu değer true ise kullanıcıların eklediği alan adı izin kuralları geçerliliğini korumaz. Standart domains eşlemesini eski allowed_domains veya denied_domains listeleriyle birlikte kullanmayın.

*.example.com yalnızca alt alan adlarıyla eşleşir. **.example.com kök alan adıyla ve onun alt alan adlarıyla eşleşir. Eşleşen bir engelleme kuralı, izin kuralına üstün gelir.

Alan adı söz dizimi, yerel/özel hedef kuralları, reddetmenin izin vermeye üstün gelmesi davranışı ve DNS yeniden bağlama sınırlamaları, Ajan onayları ve güvenlik bölümünde açıklanan korumalı alan ağı davranışıyla aynıdır.

Proxy, korumalı alan içinde çalışan yerel komutların trafiğini yönlendirir. Tarayıcı araçları da bir kaynağa erişmeden önce yönetilen ağ engelleme kurallarını ve özel izin listelerini denetler; bu ayrı bir politika denetimidir, tarayıcı trafiğinin komut proxy'si üzerinden yönlendirilmesi değildir. Web aramasını, uygulamaları ve bağlayıcıları, MCP sunucularını, yerel uygulama trafiğini, Codex hizmet isteklerini veya Codex bulut trafiğini filtrelemez. Her arayüze özgü denetimleri kullanın:

  • Web aramasını kısıtlamak için allowed_web_search_modes kullanın.
  • Uygulama ve bağlayıcı entegrasyonlarını devre dışı bırakmak için features.apps = false, desteklendiği yerlerde eklentileri devre dışı bırakmak için features.plugins = false kullanın.
  • MCP sunucularını kısıtlamak için yönetilen mcp_servers onaylı listesini kullanın.
  • Tarayıcı ve computer-use yeteneklerini kısıtlamak için browser_use, in_app_browser ve computer_use gibi özellik gereksinimlerini kullanın.
  • Codex bulut ağ erişimini bulut ortamı ayarlarından yapılandırın.

Komut alan adları için izin verilenler listesi, bu yeteneğe özgü denetimlerin yerini almaz.

Tarayıcıyı ve Computer Use'ı denetleme

Desteklenen masaüstü istemcilerini kısıtlamak için requirements.toml içindeki [browser_use] ve [computer_use] tablolarını kullanın. Politikayı dağıtımınızdaki istemci sürümleri ve işletim sistemlerinde doğrulayın. Yapılandırılmış bir izin kuralı eklenti yüklemez, işletim sistemi izni vermez veya hâlâ inceleme gerektiren bir eylemi onaylamaz.

Tarayıcı erişimi için bir kaynak politikası yapılandırın. Kaynak; şemayı, ana bilgisayarı ve isteğe bağlı bağlantı noktasını içerir; örneğin https://example.com veya https://*.example.com:8443. Yol, sorgu veya parça eklemeyin. Komut ağı alan adı kurallarından farklı olarak tarayıcı kaynak kuralları HTTP ile HTTPS arasında ayrım yapar ve bağlantı noktasıyla eşleşir.

Bu örnek, tarayıcı erişimini onaylı bir siteyle sınırlar ve o sitede yüklemeleri ve tam Chrome DevTools Protocol (CDP) erişimini engeller:

[browser_use]
allow_history_access = false
allow_global_persistent_approval = false

[browser_use.default_origin_policy]
access = "deny"

[browser_use.origins."https://example.com"]
access = "allow"
uploads = "deny"
downloads = "allow"
full_cdp_access = "deny"
persistent_approval = false
access_approval_lifetime = "turn"

Eşleşen kaynak kuralları alan bazında çözümlenir. Eşleşen bir engelleme kuralı üstün gelir; aksi hâlde varsayılan kaynak politikası, eşleşen kuralların belirtmediği alanları sağlar. Yerel yapılandırma kısıtlamalar ekleyebilir ancak yönetilen bir engelleme kuralını gevşetemez. Ağ engelleme kuralları ve özel yönetilen ağ izin listeleri uygulanmaya devam eder.

Tarayıcı eylemlerine yönelik otomatik onay incelemesini devre dışı bırakmak için browser_use.disable_auto_review = true değerini ayarlayın veya belirli bir kaynakta bunu kısıtlamak için kaynak politikasında auto_review = "deny" değerini ayarlayın. Bu, onay işlemlerini denetler; model güvenlik izlemesini devre dışı bırakmaz.

Yerel uygulamalar için varsayılan bir erişim politikası belirleyin ve izin verilen uygulamaları tanımlayın. Örneğin bu macOS politikası Calculator'a izin verir ve kaydedilmiş onayları engeller:

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

Windows politikaları, paketlenmiş uygulamaları computer_use.windows.aumids ile veya yürütülebilir dosyaları computer_use.windows.exes ile tanımlayabilir. Yürütülebilir dosya kuralları publisher_name, product_name ve access gerektirir; binary_name isteğe bağlıdır. Yalnızca görünen adı yerine uygulamanın doğrulanmış kimliğini kullanın.

Tüm alanlar için yapılandırma referansına, yönetilen macOS cihazları içinse kilitli kullanım kısıtlamalarına bakın.

Özellik bayraklarını sabitleme

Yönetilen bir requirements.toml alan kullanıcılar için özellik bayraklarını da sabitleyebilirsiniz:

[features]
personality = true
unified_exec = false

# Disable surface-specific features when needed.
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
in_app_updates = false
computer_use = false

Çalışma zamanı özellikleri için config.toml öğesinin [features] tablosundaki standart özellik anahtarlarını kullanın. Yerel çalışma zamanı tanınan özellikleri bu sabitlere uyacak şekilde normalleştirir ve config.toml ya da profil dosyası özellik ayarlarına yapılan çelişkili yazma işlemlerini reddeder.

  • in_app_browser = false, yerleşik tarayıcı bölmesini devre dışı bırakır.
  • in_app_updates = false, desteklendiği yerlerde ChatGPT masaüstü uygulamasının kendi güncelleyicisini yeniden başlatmada devre dışı bırakır. Harici paket dağıtımını etkilemez veya eski uygulama sürümlerine verilen desteği uzatmaz. Kurulum ve kullanıma sunma rehberi için Uygulama güncellemelerini yönetme sayfasına bakın.
  • browser_use = false, tarayıcılarda Computer Use'ı ve Browser Agent kullanılabilirliğini devre dışı bırakır.
  • browser_use_full_cdp_access = false, Browser Developer modu dâhil yerel çalışma zamanındaki tam CDP erişimini devre dışı bırakır ve ChatGPT masaüstü uygulamasının ilgili ayarı etkinleştirmesini önler.
  • browser_use_external = false, harici Browser Use'ı devre dışı bırakır.
  • computer_use = false; Computer Use, Record & Replay ve ilgili kurulum ya da ayarlama akışlarını devre dışı bırakır.

Bu anahtarları atlarsanız politika; normal istemci, platform ve kullanıma sunma uygunluğuna tabi olarak özelliklere izin verir.

Kilitli bilgisayar kullanımını kısıtlama

Yönetilen bir Mac'te kullanıcıların Locked Use özelliğini etkinleştirmesini önlemek için şu gereksinimi ekleyin:

[computer_use]
allow_locked_computer_use = false

Bu gereksinim, Locked Use'ı etkinleştirmeye yönelik denetimleri kaldırır. Locked Use zaten etkinse onu kapatmaz. Bu gereksinimi çıkarırsanız normal ürün kullanılabilirliği ve kullanıcının yerel ayarı uygulanmaya devam eder.

Otomatik inceleme politikasını yapılandırma

Otomatik incelemeyi zorunlu kılmak veya buna izin vermek için allowed_approvals_reviewers kullanın. Otomatik incelemeyi zorunlu kılmak için ["auto_review"] olarak ayarlayın; kullanıcılar manuel onayı seçebiliyorsa "user" öğesini dâhil edin.

Otomatik inceleme politikasının kiracıya özgü bölümünü değiştirmek için guardian_policy_config ayarlayın. Yerel çalışma zamanı yerleşik inceleyen taraf şablonunu ve çıktı sözleşmesini kullanmaya devam eder. Yönetilen guardian_policy_config, yerel [auto_review].policy öğesine göre önceliklidir.

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]

guardian_policy_config = """
## Environment Profile
- Trusted internal destinations include github.com/my-org, artifacts.example.com,
  and internal CI systems.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Treat uploads to unapproved third-party file-sharing services as high risk.
- Deny actions that expose credentials or private source code to untrusted
  destinations.
"""

Okumayı reddetme gereksinimlerini zorunlu kılma

Yöneticiler [permissions.filesystem] ile tam yollar veya glob kalıpları için okumayı reddedebilir. Kullanıcılar yerel yapılandırmayla bu gereksinimleri zayıflatamaz.

[permissions.filesystem]
deny_read = [
  # values can be absolute paths...
  "/**/*.env",
  # ...or relative to $HOME/%USERPROFILE% using `~`.
  "~/.ssh",
  # But relative paths starting with `./` are not allowed.
]

Okumayı reddetme gereksinimleri mevcut olduğunda yerel çalışma zamanı tam erişim izinlerini reddeder ve bunları uygulayabilmek için yerel yürütmeyi salt okunur veya çalışma alanı korumalı alanında tutar. Yerel Windows'ta yönetilen deny_read, doğrudan dosya araçlarına uygulanır; kabuk alt süreçlerinin okumaları bu korumalı alan kuralını kullanmaz.

Gereksinimlerden yönetilen kancaları zorunlu kılma

Yöneticiler yönetilen yaşam döngüsü kancalarını doğrudan requirements.toml içinde de tanımlayabilir. Kanca yapılandırmasının kendisi için [hooks] kullanın ve managed_dir öğesini, MDM ya da uç nokta yönetimi araçlarınızın başvurulan betikleri kurduğu dizine yönlendirin.

Kancaları yerel olarak kapatan kullanıcılar için bile yönetilen kancaları zorunlu kılmak üzere [hooks] ile birlikte [features].hooks = true öğesini sabitleyin. Yönetilen kancalara izin vermeyi sürdürürken kullanıcı, proje, oturum ve eklenti kancalarını atlamak için allow_managed_hooks_only = true ayarlayın.

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_policy.py"
command_windows = 'py -3 C:\enterprise\hooks\pre_tool_use_policy.py'
timeout = 30
statusMessage = "Checking managed Bash command"

Notlar:

  • Yerel çalışma zamanı, requirements.toml içindeki kanca yapılandırmasını zorunlu kılar ancak managed_dir içindeki betikleri dağıtmaz.
  • Bu betikleri MDM veya cihaz yönetimi çözümünüzle sunun.
  • Yönetilen kanca komutları, yapılandırılmış yönetilen dizinin altındaki mutlak betik yollarına başvurmalıdır.
  • allow_managed_hooks_only = true; kullanıcı, proje, oturum ve eklenti kaynaklarındaki kancaları atlar ancak requirements.toml ile diğer yönetilen yapılandırma katmanlarındaki kancaları yüklemeye devam eder.

Gereksinimlerden komut kurallarını zorunlu kılma

Yöneticiler, bir [rules] tablosu kullanarak requirements.toml içinden kısıtlayıcı komut kurallarını da zorunlu kılabilir. Bu kurallar normal .rules dosyalarıyla birleştirilir ve en kısıtlayıcı karar yine geçerli olur.

.rules öğesinden farklı olarak gereksinim kuralları decision belirtmelidir ve bu karar "prompt" veya "forbidden" olmalıdır ("allow" değil).

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use git clean -fd instead." },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

Yerel istemcinin hangi MCP sunucularını etkinleştirebileceğini kısıtlamak için bir mcp_servers onaylı listesi ekleyin. stdio sunucularında command, akış yapılabilir HTTP sunucularında url ile eşleştirin:

[mcp_servers.docs]
identity = { command = "codex-mcp" }

[mcp_servers.remote]
identity = { url = "https://example.com/mcp" }

identity.command öğesinin dize biçimi yalnızca yapılandırılmış command ile eşleşir. args, cwd, env veya env_vars öğelerini incelemez.

Eksiksiz bir stdio çağrısını kısıtlamak için yürütülebilir dosyayı ve her konumsal bağımsız değişkeni eşleştirin:

[mcp_servers.internal.identity]
command = { executable = "/usr/local/bin/codex-mcp", args = [
  { match = "exact", value = "serve" },
  { match = "prefix", value = "--workspace=" },
] }

Yürütülebilir dosya, bağımsız değişken sayısı ve bağımsız değişken sırası eşleşmelidir. Bağımsız değişken ve URL kuralları exact, prefix ve tam değer regex eşleştirmesini destekler. Yapılandırılmış komut kuralları yine de cwd, env veya env_vars öğelerini incelemez. Eklenti paketindeki MCP sunucuları plugins.<plugin>.mcp_servers.<server> altında aynı kimlik biçimlerini kullanır.

mcp_servers mevcut ancak boşsa yerel istemci tüm MCP sunucularını devre dışı bırakır.

Eklenti kullanılabilirliğini denetleme

Desteklenen yerel istemcilerde eklentileri kapatmak için requirements.toml içinde features.plugins değerini false olarak ayarlayın:

features.plugins = false

Bu ayar, kullanıcılar Codex'te bir API key ile oturum açtığında da uygulanır. Desteklenen yapılandırma için features.plugins referansına bakın.

Eklenti pazar yeri kaynaklarını kısıtlama

Eklenti pazaryeri kaynaklarını kısıtlamak için restrict_to_allowed_sources = true ayarını yapın ve bir veya daha fazla kaynak kuralı tanımlayın:

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.company_plugins]
source = "git"
url = "https://github.com/example/company-plugins.git"
ref = "main"

[marketplaces.allowed_sources.internal_git]
source = "host_pattern"
host_pattern = '^git\.example\.com$'

[marketplaces.allowed_sources.local_plugins]
source = "local"
path = "/opt/company/codex-plugins"

Git kuralları normalleştirilmiş depo URL'siyle ve mevcut olduğunda tam bir ref ile eşleşir. Ana makine kalıpları, küçük harfe dönüştürülmüş Git ana makinesiyle eşleştirilen düzenli ifadelerdir; tüm ana makineyi eşleştirmek için ^ ve $ kullanın. Yerel kurallar mutlak, normalleştirilmiş bir yol gerektirir. Tam şema ve birleştirme davranışı için requirements.toml referansına bakın.

Bu gereksinimler, kurallarla eşleşmeyen pazaryeri ekleme, eklenti yükleme ve yapılandırılmış Git pazaryerlerini yenileme işlemlerini reddeder. Ayrıca yapılandırılmış pazaryerlerini ve bunların eklentilerini çalışma zamanında filtreler.

API key kataloğu dahil, OpenAI tarafından seçilip düzenlenen Git pazaryerleri de kaynak izin listesiyle eşleşmelidir. Bunlara izin vermek için aşağıdaki Git kaynağını ref kısıtlaması olmadan ekleyin:

[marketplaces.allowed_sources.openai_curated]
source = "git"
url = "https://github.com/openai/plugins.git"

Seçilip düzenlenen katalogları hariç tutmak için bu kaynağı eklemeyin ve daha geniş kapsamlı hiçbir ana makine kuralının buna izin vermediğinden emin olun. Birlikte sunulan eklentiler ve uzaktan yüklenen çalışma alanı eklentileri, seçilip düzenlenen Git kaynaklarına ilişkin bu ilkeden ayrıdır.

Bu kaynak kısıtlamaları yalnızca yerel bir istemcinin eklenti pazar yeri işlemlerini desteklediği yerlerde geçerlidir: masaüstü uygulamasındaki ChatGPT ve Codex ile Codex CLI. ChatGPT'nin web veya mobil sürümünde eklenti kullanımını denetlemez ve IDE uzantısına eklenti eklemez.

Yönetilen varsayılanlar (managed_config.toml)

Yönetilen varsayılanlar, desteklenen bir yerel istemcinin başlangıçta kullanacağı yapılandırmayı belirler. İstemci başlatılırken kullanıcının yerel config.toml değerini ve tüm CLI --config geçersiz kılmalarını geçersiz kılar. Kullanıcılar geçerli çalıştırma sırasında bu ayarları yine değiştirebilir ve istemci bir sonraki kez başlatıldığında varsayılanlar yeniden uygulanır.

Yönetilen bir varsayılan ayar, macOS MDM profili veya kaydedilmiş yapılandırma, ChatGPT ile oturum açan Codex kullanıcıları için gpt-5.5 modelini sabitliyorsa bunu 14 Ekim 2026 tarihinden önce gpt-5.6-sol ile değiştirin. GPT-5.5, o tarihte tüm planlarda ChatGPT, ChatGPT Work ve Codex'ten kaldırılacaktır. OpenAI API bundan etkilenmez. Çalışma alanında model kullanılabilirliği bölümüne bakın.

Yönetilen bir varsayılan, macOS MDM profili veya kayıtlı yapılandırma, ChatGPT ile oturum açan kullanıcılar için gpt-5.4 ya da gpt-5.4-mini öğesini sabitliyorsa 31 Ağustos 2026'dan önce güncelleyin. gpt-5.4 yerine gpt-5.6-terra, gpt-5.4-mini yerine gpt-5.6-luna kullanın. OpenAI API ve kendi API key anahtarınızla kimlik doğrulanan Codex bundan etkilenmez. Çalışma alanı modeli kullanılabilirliği sayfasına bakın.

Yönetilen varsayılanlarınızın gereksinimlerinizi karşıladığından emin olun; yerel çalışma zamanı izin verilmeyen değerleri reddeder.

Öncelik ve katmanlama

Yerel çalışma zamanı etkin yapılandırmayı şu sırayla oluşturur (üstteki alttakini geçersiz kılar):

  • Yönetilen tercihler (macOS MDM; en yüksek öncelik)
  • managed_config.toml (sistem/yönetilen dosya)
  • config.toml (kullanıcının temel yapılandırması)

CLI --config key=value geçersiz kılmaları temele uygulanır, ancak yönetilen katmanlar bunları geçersiz kılar. Bu, yerel bayraklar sağlasanız bile her çalışmanın yönetilen varsayılanlardan başladığı anlamına gelir.

Buluttaki config.toml, normal yapılandırma önceliğini kullanır; yukarıdaki eski sıralamayı kullanmaz. Buluttaki requirements.toml ise gereksinim önceliğini kullanır.

Konumlar

  • Linux/macOS (Unix): /etc/codex/managed_config.toml
  • Windows/Unix dışı: ~/.codex/managed_config.toml

Dosya yoksa yerel çalışma zamanı yönetilen katmanı atlar.

macOS yönetilen tercihleri (MDM)

macOS'ta yöneticiler, base64 ile kodlanmış TOML yüklerini şu konumda sağlayan bir cihaz profili gönderebilir:

  • Tercih alanı: com.openai.codex
  • Anahtarlar:
    • config_toml_base64 (yönetilen varsayılanlar)
    • requirements_toml_base64 (gereksinimler)

Yerel çalışma zamanı bu "yönetilen tercihler" yüklerini TOML olarak ayrıştırır. Yönetilen varsayılanlar (config_toml_base64) için yönetilen tercihler en yüksek önceliğe sahiptir. Gereksinimler (requirements_toml_base64) için öncelik yukarıda açıklanan bulut tarafından yönetilen gereksinimler sırasını izler. Gereksinimler tarafındaki aynı [features] tablosu requirements_toml_base64 içinde çalışır; burada da standart özellik anahtarlarını kullanın.

MDM kurulum iş akışı

Yerel çalışma zamanı standart macOS MDM yüklerini destekler; dolayısıyla ayarları Jamf Pro, Fleet veya Kandji gibi araçlarla dağıtabilirsiniz. Hafif bir dağıtım şöyle görünür:

  1. Yönetilen yük TOML'sini oluşturun ve base64 ile kodlayın (satır kaydırma olmadan).
  2. Dizeyi MDM profilinizde com.openai.codex alanı altındaki config_toml_base64 (yönetilen varsayılanlar) veya requirements_toml_base64 (gereksinimler) konumuna bırakın.
  3. Profili gönderin, ardından kullanıcılardan desteklenen yerel istemciyi yeniden başlatmalarını ve başlangıç yapılandırması özetinin yönetilen değerleri yansıttığını doğrulamalarını isteyin.
  4. Politikayı iptal ederken veya değiştirirken yönetilen yükü güncelleyin; istemci yenilenmiş tercihi bir sonraki başlatılışında okur.

Yüke gizli bilgiler veya sık değişen dinamik değerler yerleştirmekten kaçının. Yönetilen TOML'yi değişiklik denetimi altındaki diğer MDM ayarları gibi ele alın.

Örnek managed_config.toml

# Set conservative defaults
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # keep network disabled unless explicitly allowed

[otel]
environment = "prod"
exporter = "otlp-http"            # point at your collector
log_user_prompt = false            # keep prompts redacted
# exporter details live under exporter tables; see Monitoring and telemetry above

Önerilen güvenlik sınırları

  • Çoğu kullanıcı için onaylarla birlikte workspace-write tercih edin; tam erişimi denetimli kapsayıcılara ayırın.
  • Güvenlik incelemeniz bir toplayıcıya veya iş akışlarınızın gerektirdiği alan adlarına izin vermedikçe network_access = false değerini koruyun.
  • OTel ayarlarını (dışa aktarıcı, ortam) sabitlemek için yönetilen yapılandırmayı kullanın, ancak politikanız istem içeriklerinin saklanmasına açıkça izin vermedikçe log_user_prompt = false değerini koruyun.
  • Sapmaları yakalamak için yerel config.toml ile yönetilen politika arasındaki farkları düzenli olarak denetleyin; yönetilen katmanlar yerel bayraklara ve dosyalara üstün gelmelidir.