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

Yönetilen yapılandırma

Desteklenen yerel istemciler genelinde çalışma zamanı gereksinimlerini zorunlu kılın ve yönetilen varsayılanları dağıtı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ışını iki şekilde denetleyebilir:

  • Gereksinimler: Kullanıcıların geçersiz kılamadığı, yönetici tarafından zorunlu kılınan kısıtlamalar.
  • Yönetilen varsayılanlar: Desteklenen bir istemci başlatıldığında uygulanan başlangıç değerleri. Kullanıcılar çalışma sırasında ayarları değiştirmeye devam edebilir; istemci bir sonraki başlatılışında yönetilen varsayılanları yeniden uygular.

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 araması modu, yönetilen kancalar, kullanıcıların hangi MCP sunucularını etkinleştirebileceği ve kullanıcı tarafından yapılandırılmış hangi eklenti pazar yeri kaynaklarını ekleyebileceği, bunlardan kurulum yapabileceği veya bunları yenileyebileceği) kısıtlar. Yapılandırma çözümlenirken (örneğin config.toml, profil dosyaları veya CLI yapılandırma geçersiz kılmaları üzerinden), bir değer zorunlu kılınan bir kuralla çelişirse yerel istemci uyumlu bir değere geri döner ve kullanıcıyı bilgilendirir. Bir mcp_servers izin listesi yapılandırırsanız istemci, yalnızca hem adı hem de kimliği onaylanmış bir kayıtla eşleşen MCP sunucusunu etkinleştirir; aksi takdirde sunucuyu 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.

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 planda ChatGPT ile oturum açtığında desteklenen yerel istemciler, çalışma alanıyla ilişkilendirilmiş ve yönetici tarafından zorunlu kılınan gereksinimleri alabilir. Bu, requirements.toml ile uyumlu politika için bir dağıtım kanalıdır. Çalışma alanına erişim sağlamaz veya çalışma alanı RBAC'sinin yerini almaz.

Bulut tarafından yönetilen gereksinimler oluşturmak ve atamak için Yönetilen yapılandırma sayfasını açın. Örneğin bu politika, desteklenen istemcilerin Amerika Birleşik Devletleri veri yerleşimini kullanmasını zorunlu kılar, onay ve korumalı alan seçeneklerini sınırlar ve desteklenen bir kabuk giriş noktası çalışmadan önce kullanıcıdan onay ister:

enforce_residency = "us"
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.

Ö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"]

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ı features.network_proxy geçiş düğmesinden ayrıdır: korumalı alan ağını bu özellik bayrağı olmadan yapılandırabilirler, ancak etkin korumalı alan ağı kapalı tuttuğunda komutlara ağ erişimi sağlamazlar.

experimental_network.enabled = true
experimental_network.allowed_domains = [
  "api.openai.com",
  "*.example.com",
]
experimental_network.denied_domains = [
  "blocked.example.com",
  "*.exfil.example.com",
]

experimental_network.managed_allowed_domains_only = true öğesini yalnızca yöneticiye ait allowed_domains kurallarını da tanımladığınızda ve bu izin listesinin özel olmasını istediğinizde kullanın. Yönetilen izin kuralları olmadan true ise kullanıcıların eklediği alan adı izin kuralları geçerliliğini korumaz.

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.

Ö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 kilitlendikten sonra Computer Use özelliğinin çalışmasını önlemek için şu gereksinimi ekleyin:

[computer_use]
allow_locked_computer_use = false

Bu gereksinim Computer Use'ı etkinleştirmez. Yalnızca macOS'ta kilitli kullanımı önler. Atlarsanız gereksinimler kilitli kullanımı kısıtlamaz; normal ürün kullanılabilirliği ve kullanıcının yerel ayarı geçerliliğini korur.

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

Kullanıcı tarafından yapılandırılmış pazar yeri kaynaklarındaki işlemleri kısıtlamak için restrict_to_allowed_sources = true ayarlayı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, kullanıcı tarafından yapılandırılmış kaynaklarda eşleşmeyen pazar yeri ekleme, eklenti kurma ve yapılandırılmış Git pazar yerini yenileme işlemlerini reddeder. Codex tarafından yönetilen OpenAI pazar yerleri, kaynakları ve ayrılmış adları eşleştiğinde kullanılabilir kalır. Gereksinimler, önceden yapılandırılmış kullanıcı pazar yerlerini veya bunların eklentilerini çalışma zamanında filtrelemez.

Bu kaynak kısıtlamaları yalnızca yerel istemcinin eklenti pazar yeri işlemlerini desteklediği yerlerde uygulanır: masaüstü uygulamasındaki ChatGPT Work ve Codex ile Codex CLI. Chat'e, IDE uzantısına veya mobil uygulamaya eklenti eklemezler.

Yönetilen varsayılanlar (managed_config.toml)

Yönetilen varsayılanlar, kullanıcının yerel config.toml yapılandırmasının üzerine birleştirilir ve tüm CLI --config geçersiz kılmalarından öncelikli olarak, desteklenen bir yerel istemci başlatıldığında başlangıç değerlerini ayarlar. Kullanıcılar çalışma sırasında bu ayarları değiştirmeye devam edebilir; istemci bir sonraki başlatılışında yönetilen varsayılanları yeniden uygular.

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.

Bulut tarafından yönetilen gereksinimler, gereksinimler katmanını etkiler (yönetilen varsayılanları değil). Öncelik için yukarıdaki Yönetici tarafından zorunlu kılınan gereksinimler bölümüne bakın.

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.