託管設定
在受支援的本機客戶端中強制執行執行時要求,並分發受管預設設定
託管設定用於控制 ChatGPT 桌面 App、Codex CLI 和 IDE 擴充套件中受支援能力的本機執行時行為。不同客戶端和版本支援的強制規則可能不同。託管設定不會授予 ChatGPT 工作區存取權限、分配席位,也不會取代工作區基於角色的存取控制(RBAC)。工作區功能存取參見角色和工作區權限;本頁面只說明本機執行時策略。
企業管理員可以通過兩種方式控制受支援的本機客戶端行為:
- 強制規則(Requirements): 管理員強制執行的約束,使用者不能覆蓋。
- 託管預設值(Managed defaults): 受支援客戶端啟動時應用的初始值。使用者在當前執行中仍可修改,但客戶端下次啟動時會重新應用託管預設值。
管理員強制規則(requirements.toml)
requirements.toml 用來限制安全相關設定,例如審批策略、審批審查者、自動審查策略、沙箱模式、權限設定檔、Web 搜尋模式、託管鉤子、允許使用者啟用哪些 MCP servers,以及允許使用者新增、安裝或重新整理的自定義外掛市場來源。本機客戶端彙總設定時,例如讀取 config.toml、設定檔檔案或 CLI 設定覆蓋項,如果某個值與強制規則衝突,會回退到相容值並通知使用者。
如果為 mcp_servers 設定允許列表,只有 MCP server 的名稱與身份都匹配獲准條目時,本機客戶端才會啟用;否則會將其停用。
還可以通過 requirements.toml 的 [features] 表限制功能開關。功能不一定都與安全相關,但企業可以按需固定值;省略的鍵不受約束。
對於 Codex 0.138.0 或更新版本,優先使用權限設定檔,也就是通過 allowed_permission_profiles 搭配託管的 default_permissions。只有仍設定 sandbox_mode 的舊部署,才使用 allowed_sandbox_modes。
完整鍵列表參見設定參考中的 requirements.toml。
位置與優先順序
每個受支援的本機客戶端從低到高組合以下強制規則來源:
- 系統
requirements.toml:Unix(包括 Linux 和 macOS)上的/etc/codex/requirements.toml,或 Windows 上的%ProgramData%\OpenAI\Codex\requirements.toml。 - 通過雲端設定包下發的企業託管強制規則。
- 本機客戶端重新解釋為強制規則的舊
managed_config.toml欄位。 - 通過
com.openai.codex:requirements_toml_base64下發的 macOS 託管偏好設定(MDM)。
高優先順序層會覆蓋低優先順序層中的普通標量和列表值。表按鍵合併;規則、鉤子和檔案系統限制等強制規則則使用各欄位特定的組合方式。當前結構定義應以 requirements.toml 參考為準,不要假設所有欄位採用同一種合併方式。
為保持向後相容,受支援的本機客戶端會把舊 approval_policy、approvals_reviewer 和 sandbox_mode 欄位重新解釋為強制規則,並在需要時補充相容選項。需要顯式允許列表時,應改用 requirements.toml。
雲端託管強制規則
使用者通過受支援套餐的 ChatGPT 賬號登入後,受支援的本機客戶端可以接收與該工作區關聯的管理員強制規則。這是一種與 requirements.toml 相容的策略下發渠道,不會授予工作區存取權限,也不會替代工作區 RBAC。
開啟 Managed configuration(託管設定),建立並分配雲端託管強制規則。例如,以下策略要求受支援客戶端使用美國資料駐留,限制審批與沙箱選擇,並在受支援的 shell 入口執行前請求確認:
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" },
]請確認每個託管客戶端版本都支援所選鍵,並先在小範圍群組中測試,再分配給整個組織。當前結構定義以設定參考為準;工作區端建立與分配行為則以管理介面為準。
服務會選擇適用於當前登入身份的企業託管強制規則層。本機客戶端再按照位置與優先順序與其他強制規則來源組合。工作區端建立與分配行為由管理服務負責,可能獨立於本機強制規則格式變化,因此不要依賴複製出來的群組匹配演算法。
支援的鍵和範例參見 requirements.toml 範例和 requirements.toml 參考。
本機客戶端如何應用雲端託管強制規則
使用者啟動受支援的本機客戶端並通過受支援套餐的 ChatGPT 賬號登入時,客戶端會先檢查與當前身份匹配且仍有效的快取條目。若不存在,則通過重試從服務拉取適用的設定包,並在成功後寫入簽名快取。如果請求失敗或超時,同時沒有有效快取,雲端設定包載入會返回錯誤,而不是在缺少雲端託管強制規則層的情況下靜默啟動。
解析快取後,客戶端會按上面的規則把雲端強制規則與其他強制規則層組合。後臺重新整理可以更新下次啟動使用的快取,但不會替換當前程序已經載入的強制規則。
requirements.toml 範例
下面這個範例會阻止使用 --ask-for-approval never 和 --sandbox danger-full-access,其中也包括 --yolo:
allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]停用 Appshots
如果要為受管理使用者停用 Appshots,請設定頂層 allow_appshots 強制規則:
allow_appshots = false在 Appshots 可用的產品中,allow_appshots = false 會將其停用。如果省略該鍵,強制規則不會約束 Appshots,仍按正常產品可用性檢查決定。通過 configRequirements/read 讀取實際生效強制規則的 app-server 客戶端會收到同樣的 allowAppshots 限制;省略或設為 null 不會停用 Appshots。
停用裝置遠端控制
如果要為受管理使用者停用裝置遠端控制,請設定頂層 allow_remote_control 強制規則:
allow_remote_control = false在支援裝置遠端控制的產品中,allow_remote_control = false 會將其停用。如果省略該鍵,強制規則不會約束裝置遠端控制,仍按正常產品可用性檢查決定。該強制規則不會停用 SSH 遠端連線。
控制可用權限設定檔
使用 allowed_permission_profiles 可以控制使用者能選擇哪些內建和自定義權限設定檔。它是 allowed_sandbox_modes 對應的權限設定檔允許列表;請根據使用者實際選擇權限的方式使用對應允許列表。
權限設定檔允許列表要求 Codex 0.138.0 或更新版本。Codex 0.137.0 及更早版本會忽略 allowed_permission_profiles 和託管的 default_permissions。
只有在所有受管理客戶端都執行支援版本後,才使用下面的權限設定檔範例。不要在客戶端群升級完成前部署託管自定義設定檔。
當 [allowed_permission_profiles] 表存在時,它就是完整的允許列表。設為 true 的設定檔會被允許;省略或設為 false 的設定檔會被拒絕,包括未來 Codex 版本新增的內建設定檔。
允許標準設定檔
下面的策略允許只讀和工作區存取,但不允許完全存取:
default_permissions = ":workspace"
[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# 省略 ":danger-full-access",因此它会被拒绝。新增託管的最小權限預設值
管理員可以在同一個強制規則來源中定義自定義設定檔。請使用不會和使用者已載入設定裡的名稱衝突的組織專屬名稱。自定義名稱不能以 : 開頭,也不能使用保留名稱 filesystem。
不要把託管自定義設定檔部署到執行 Codex 0.137.0 或更早版本的客戶端。那些客戶端能識別設定檔表,但不能識別選擇它的託管預設值。
例如:
default_permissions = "acme_review_only"
[allowed_permission_profiles]
":read-only" = true
":workspace" = true
acme_review_only = true
# 有意省略 ":danger-full-access",因此它会被拒绝。
[permissions.acme_review_only]
description = "Review code without modifying the workspace."
extends = ":read-only"只允許企業定義的設定檔
如果使用者只能選擇管理員定義的設定檔,請省略所有內建項:
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"這個自定義設定檔可以擴充套件 :workspace,即使使用者不能直接選擇內建的 :workspace 設定檔。
關閉另一個來源允許的設定檔
權限允許列表按設定檔名稱合併。由於雲端強制規則的優先順序高於系統強制規則,雲端強制規則可以用 false 關閉系統檔案允許的設定檔。
雲端強制規則:
default_permissions = ":read-only"
[allowed_permission_profiles]
":read-only" = true
":workspace" = false系統強制規則:
[allowed_permission_profiles]
":read-only" = true
":workspace" = true # 不会生效,因为云端强制规则将它设为了 false。請顯式把 default_permissions 設為一個允許的設定檔。如果省略它,只有當 :workspace 和 :read-only 都被顯式允許時,本機執行時才會預設使用 :workspace。當 allowed_permission_profiles 不存在時,託管強制規則不會限制使用者可選擇的設定檔名稱。每個條目都必須指向內建設定檔,或指向已載入設定或強制規則來源中定義的自定義設定檔。如果希望集中控制自定義設定檔行為,請在託管強制規則中定義。
按主機覆蓋沙箱強制規則
當同一份託管策略需要在不同主機上應用不同的沙箱要求時,可以使用 [[remote_sandbox_config]]。例如,你可以為筆記本保留更嚴格的預設值,同時允許匹配的 dev box 或 CI runner 使用 workspace-write。主機級條目當前只會覆蓋 allowed_sandbox_modes:
allowed_sandbox_modes = ["read-only"]
[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]本機執行時會把每個 hostname_patterns 條目與盡力解析出的主機名比較。可用時優先使用完整限定域名,否則回退到本機主機名。匹配不區分大小寫;* 匹配任意字元序列,? 匹配單個字元。
在同一個強制規則來源中,第一個命中的 [[remote_sandbox_config]] 條目生效。如果沒有條目命中,本機執行時會保留頂層的 allowed_sandbox_modes。主機名匹配只用於策略選擇,不應把它當作已認證的裝置證明。
你也可以限制 Web 搜尋模式:
allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowedallowed_web_search_modes = [] 表示只允許 "disabled"。
例如,allowed_web_search_modes = ["cached"] 會禁止即時 Web 搜尋,即使使用者當前會話執行在 danger-full-access 模式下也一樣。
設定網路存取要求
當管理員需要集中定義網路存取要求時,可以在 requirements.toml 中使用 [experimental_network]。這些要求獨立於使用者側的 features.network_proxy 開關:它們可以在不啟用該功能開關的情況下設定沙箱網路,但如果當前啟用的沙箱本身關閉了命令聯網,它們不會授予命令網路存取。
experimental_network.enabled = true
experimental_network.allowed_domains = [
"api.openai.com",
"*.example.com",
]
experimental_network.denied_domains = [
"blocked.example.com",
"*.exfil.example.com",
]只有在同時定義了管理員管理的 allowed_domains,並且希望這個允許列表成為唯一有效列表時,才使用 experimental_network.managed_allowed_domains_only = true。如果它為 true 但沒有託管的 allow 規則,使用者新增的域名 allow 規則也不會繼續生效。
域名語法、本機或私有目的地規則、deny 優先於 allow 的行為,以及 DNS rebinding 限制,都與智能體審批與安全中描述的沙箱網路行為一致。
固定功能開關
你也可以為接收託管 requirements.toml 的使用者固定功能開關的取值:
[features]
personality = true
unified_exec = false
# 需要时禁用特定产品形态的功能。
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
in_app_updates = false
computer_use = false執行時功能應使用 config.toml 的 [features] 表中定義的權威鍵名。本機執行時會規範化已識別功能以滿足固定值,並拒絕把衝突設定寫入 config.toml 或設定檔檔案中的功能設定。
in_app_browser = false會停用內建瀏覽器面板。in_app_updates = false會在支援的環境中停用 ChatGPT 桌面 App 重啟時執行的內建更新程式。它不會影響外部軟體包部署,也不會延長舊版 App 的支援週期。設定與釋出指導請參見管理 App 更新。browser_use = false會停用瀏覽器中的 Computer Use 和 Browser Agent 可用性。browser_use_full_cdp_access = false會停用本機執行時中的完整 CDP 存取,包括 Browser Developer mode(瀏覽器開發者模式),並阻止 ChatGPT 桌面 App 開啟對應設定。browser_use_external = false會停用外部 Browser Use。computer_use = false會停用 Computer Use、Record & Replay 及相關安裝或設定流程。
如果省略這些鍵,策略會允許這些功能;實際可用性仍取決於普通客戶端、平台和灰度釋出條件。
限制鎖定狀態下的計算機操作
若要阻止 Computer Use 在託管 Mac 鎖定後繼續操作,請新增這項強制規則:
[computer_use]
allow_locked_computer_use = false這項強制規則不會啟用 Computer Use。它只會阻止 macOS 上的鎖定狀態使用。如果省略它,鎖定狀態使用不會受強制規則約束,仍然取決於普通產品可用性和使用者本機設定。
設定自動審查策略
使用 allowed_approvals_reviewers 可以要求或允許自動審查。若設為 ["auto_review"],就表示必須使用自動審查;若同時包含 "user",則使用者仍可手動選擇人工審批。
使用 guardian_policy_config 可以覆蓋自動審查策略裡與租戶相關的那一部分內容。Codex 仍會沿用內建的審查器模板和輸出契約。託管的 guardian_policy_config 優先順序高於本機的 [auto_review].policy。
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.
"""強制執行 deny-read 要求
管理員可以通過 [permissions.filesystem] 拒絕讀取精確路徑或 glob 模式。使用者不能用本機設定放寬這些強制要求。
[permissions.filesystem]
deny_read = [
# 值可以是绝对路径...
"/**/*.env",
# ...也可以用 `~` 表示相对于 $HOME/%USERPROFILE%。
"~/.ssh",
# 但不允许使用以 `./` 开头的相对路径。
]設定了讀取拒絕(deny-read)強制規則後,Codex 會將本機沙箱模式限定為 read-only 或 workspace-write,這樣 Codex 才能真正執行這些限制。在原生 Windows 上,管理員下發的 deny_read 只適用於直接操作檔案的工具;通過 shell 子程序發起的讀取不會套用這項沙箱規則。
通過強制規則執行託管鉤子
管理員也可以直接在 requirements.toml 中定義託管生命週期鉤子。使用 [hooks] 編寫鉤子設定本身,並讓 managed_dir 指向你的 MDM 或終端管理工具安裝相關指令碼的目錄。
若要即使使用者在本機關閉鉤子也強制執行託管鉤子,請把 [features].hooks = true 與 [hooks] 一起固定下來。若要跳過使用者、專案、會話和外掛鉤子,同時仍允許託管鉤子,請設定 allow_managed_hooks_only = true。
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"注意事項:
- Codex 會強制執行
requirements.toml中的鉤子設定,但不會分發managed_dir中的指令碼。 - 請用 MDM 或裝置管理方案單獨分發這些指令碼。
- 託管鉤子命令應引用設定的託管目錄下的絕對指令碼路徑。
allow_managed_hooks_only = true會跳過來自使用者、專案、會話和外掛來源的鉤子,但仍會載入requirements.toml和其他託管設定層裡的託管鉤子。
通過強制規則執行命令規則
管理員還可以在 requirements.toml 的 [rules] 表裡寫入更嚴格的命令規則。這些規則會和普通 .rules 檔案一起生效,最後仍以限制更嚴格的結果為準。
和 .rules 不同,這裡的每條規則都必須顯式寫出 decision,而且只能是 "prompt" 或 "forbidden",不能寫 "allow"。
[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." },
]如果你要限制使用者可以啟用哪些 MCP servers,可以為 mcp_servers 設定允許列表。對於 stdio server,要匹配 command;對於 streamable HTTP server,要匹配 url:
[mcp_servers.docs]
identity = { command = "codex-mcp" }
[mcp_servers.remote]
identity = { url = "https://example.com/mcp" }identity.command 的字串形式只匹配設定裡的 command,不會檢查 args、cwd、env 或 env_vars。
如果要約束完整的 stdio 呼叫,需要同時匹配執行檔和每個位置參數:
[mcp_servers.internal.identity]
command = { executable = "/usr/local/bin/codex-mcp", args = [
{ match = "exact", value = "serve" },
{ match = "prefix", value = "--workspace=" },
] }執行檔、參數數量和參數順序都必須匹配。參數規則和 URL 規則支援 exact、prefix 以及匹配完整值的 regex。結構化 command 規則仍不會檢查 cwd、env 或 env_vars。外掛打包的 MCP server 在 plugins.<plugin>.mcp_servers.<server> 下使用同樣的身份規則形態。
如果 mcp_servers 存在但為空,Codex 會停用所有 MCP servers。
控制 plugin 可用性
如需在受支援的本機客戶端中關閉 plugins,請在 requirements.toml 中把 features.plugins 設為 false:
features.plugins = false使用者使用 API key 登入 Codex 時,此設定同樣生效。支援的設定見 features.plugins 參考。
限制外掛市場來源
如果要限制針對使用者自定義外掛市場來源的操作,請設定 restrict_to_allowed_sources = true,並定義一個或多個來源規則:
[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 規則會匹配規範化後的儲存庫 URL;如果寫了 ref,還會要求精確匹配該 ref。host_pattern 是針對小寫 Git 主機名的正規表示式;如果要匹配完整主機名,請使用 ^ 和 $。local 規則要求絕對且規範化後的路徑。完整結構定義與合併行為參見 requirements.toml 參考。
這些強制規則會拒絕新增不匹配的外掛市場、安裝外掛,以及重新整理已設定的 Git 外掛市場,但只作用於使用者自定義來源。只要來源和保留名稱匹配,Codex 管理的 OpenAI 外掛市場仍然可用。這些強制規則不會在執行時過濾已經設定好的使用者外掛市場或其中的外掛。
這些來源限制只應用於支援外掛市場操作的本機客戶端:桌面 App 中的 ChatGPT Work 與 Codex,以及 Codex CLI。它們不會把外掛新增到 Chat、IDE 擴充套件或移動端。
託管預設值(managed_config.toml)
managed_config.toml 會合併到使用者本機 config.toml 之上,也會壓過 CLI 的 --config 覆蓋項,為受支援的本機客戶端提供啟動初始值。使用者在當前執行中仍可修改,但客戶端下次啟動時會重新應用託管預設值。
如果託管預設值、macOS MDM 設定檔或已儲存設定為使用 ChatGPT 登入的使用者固定了 gpt-5.4 或 gpt-5.4-mini,請在 2026 年 8 月 31 日前完成更新:將 gpt-5.4 替換為 gpt-5.6-terra,並將 gpt-5.4-mini 替換為 gpt-5.6-luna。OpenAI API 和使用自有 API key 認證的 Codex 不受影響。詳情見工作區模型可用性。
請確保託管預設值符合強制規則;不允許的值會被本機執行時拒絕。
優先順序與疊加關係
本機執行時按以下順序生成實際生效設定,越靠上的層優先順序越高:
- macOS 託管偏好設定(MDM,最高優先順序)
managed_config.toml(系統級或託管檔案)config.toml(使用者基礎設定)
CLI --config key=value 只作用在基礎層,但仍會被託管層覆蓋。這意味著即使使用者本機傳了參數,每次啟動仍會先回到託管預設值。
雲端託管強制規則影響的是強制規則層,不屬於託管預設值層。它的優先順序請參見上面的“管理員強制規則”。
位置
- Linux / macOS(Unix):
/etc/codex/managed_config.toml - Windows / 非 Unix:
~/.codex/managed_config.toml
如果檔案不存在,本機執行時會跳過這一層託管設定。
macOS 託管偏好設定(MDM)
在 macOS 上,管理員可以通過裝置設定描述檔案下發 base64 編碼的 TOML 內容:
- 偏好設定域:
com.openai.codex - 鍵:
config_toml_base64(託管預設值)requirements_toml_base64(強制規則)
本機執行時會把這些託管偏好設定載荷按 TOML 解析。對於託管預設值 config_toml_base64,託管偏好設定擁有最高優先順序;對於強制規則 requirements_toml_base64,優先順序遵循上文雲端託管強制規則的順序。
在 requirements_toml_base64 裡同樣可以使用 [features] 表,這裡也要使用標準鍵名。
MDM 設定流程
本機執行時相容標準 macOS MDM payload,因此可以用 Jamf Pro、Fleet 或 Kandji 等工具下發設定。一個簡潔的部署流程如下:
- 寫好要下發的 TOML,再用
base64編碼,編碼結果不要換行。 - 把編碼後的字串放進 MDM 設定描述檔案的
com.openai.codex域,寫到config_toml_base64(託管預設值)或requirements_toml_base64(強制規則)。 - 下發設定描述檔案後,讓使用者重啟受支援的本機客戶端,並確認啟動設定摘要已經反映託管值。
- 如果需要撤銷或調整策略,請更新託管載荷;客戶端會在下次啟動時讀取新的偏好設定。
不要在這份內容裡寫入金鑰或頻繁變動的動態值。應把這份託管 TOML 當作正式受控設定來管理,和其他需要走變更流程的 MDM 設定保持同樣的管理方式。
managed_config.toml 範例
# 使用较保守的默认值
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = false # 默认关闭网络,除非明确允许
[otel]
environment = "prod"
exporter = "otlp-http" # 指向你的日志采集端
log_user_prompt = false # 不记录用户提示词内容
# exporter 的详细配置写在对应的 exporter 表中;参见上方监控与遥测说明推薦防護欄
- 對大多數使用者,優先使用需要審批的
workspace-write;只有在受控容器環境中,才考慮開放完全存取。 - 除非你的安全評估已經允許存取 OTel 採集端或工作流程所需域名,否則應保持
network_access = false。 - 可以用託管設定固定 OTel 的
exporter、environment等設定,但除非策略明確允許儲存提示詞內容,否則應保持log_user_prompt = false。 - 應定期檢查本機
config.toml與託管策略之間的差異,及時發現設定漂移;最終應始終以託管層覆蓋本機檔案和命令列參數。