託管設定

託管設定用於控制 ChatGPT 桌面應用、Codex CLI 和 IDE 擴充套件中所涵蓋功能的受支援本機執行時行為。受支援的要求可能因客戶端和版本而異。託管設定不會授予 ChatGPT 工作區存取權限、分配席位，也不會取代工作區基於角色的存取控制 (RBAC)。有關工作區功能存取權限，請參閱角色和工作區權限；有關本機執行時策略，請參閱本頁。

企業管理員可以通過以下方式控制受支援的本機客戶端行為：

• 要求：管理員強制執行的約束，使用者無法覆蓋。
• 設定預設值：由系統或雲端管理的 config.toml 設定，使用者可以覆蓋。
• 舊版託管預設值：受支援的客戶端啟動時應用的 managed_config.toml 初始值。使用者仍可在執行期間更改設定；客戶端會在下次啟動時重新應用這些預設值。

設定外掛市場和預設值

在系統 config.toml 中定義本機或 Git 外掛市場和外掛預設值， 也可以在託管設定的 config.toml 部分中定義。 這些設定是預設值，不是強制執行的策略。

有關設定鍵，請參閱設定參考； 設定優先順序 介紹了覆蓋規則，儲存庫外掛設定 介紹了專案級設定。工作區 GitHub 匯入與 同步是單獨的功能。

管理員強制執行的要求 (requirements.toml)

要求用於約束安全敏感設定（審批策略、審批稽核者、自動稽核策略、沙盒模式、權限設定檔、網頁搜尋模式、託管鉤子、使用者可啟用的 MCP 伺服器，以及可使用的外掛市場來源）。解析設定時（例如來自 config.toml、設定檔或 CLI 設定覆蓋項的設定），如果某個值與強制執行的規則衝突，本機客戶端會回退到相容值並通知使用者。如果你設定了 mcp_servers 允許列表，客戶端僅在 MCP 伺服器的名稱和身份均匹配某個已核准條目時才會啟用該伺服器；否則會將其停用。

要求還可以通過 requirements.toml 中的 [features] 表約束功能標誌。請注意，功能不一定都涉及安全，但企業可以根據需要固定其值。省略的鍵不受約束。

對於 Codex 0.138.0 或更高版本，建議使用帶有 allowed_permission_profiles 和託管 default_permissions 的權限設定檔。僅對仍在設定 sandbox_mode 的舊版部署使用 allowed_sandbox_modes。

有關確切的鍵列表，請參閱《設定參考》中的 requirements.toml 部分。

遷移已停用的 untrusted 審批策略

Codex 和 ChatGPT Work 不再支援 approval_policy = "untrusted"。 請從託管預設值、舊版 managed_config.toml，以及所有設定了該值的使用者、 專案、設定檔或啟動設定中移除它。

對於互動式只讀使用場景，選擇 approval_policy = "on-request"，並搭配 受管要求允許的只讀沙箱或權限設定檔。 該沙箱允許的命令無需審批即可執行。

要保留更嚴格的命令審批，請勿顯式設定 approval_policy，並將 trust_level = "untrusted" 設定在使用者級設定檔中的專案條目內，檔案路徑為 ~/.codex/config.toml，同時在 allowed_approval_policies 中保留 untrusted。 這也會停用專案本機設定。顯式設定 on-request 會覆蓋該策略。有關範例和安全權衡，請參閱 從已停用的 untrusted 審批策略遷移 中的說明。

位置和優先順序

每個受支援的本機客戶端都按從低到高的優先順序組合要求：

1. 系統 requirements.toml（Unix 系統上的 /etc/codex/requirements.toml，包括 Linux 和 macOS；或 Windows 上的 %ProgramData%\OpenAI\Codex\requirements.toml）。
2. 通過雲設定包交付的企業託管要求。
3. 本機客戶端重新解釋為要求的舊版 managed_config.toml 欄位。
4. 通過 com.openai.codex:requirements_toml_base64 交付的 macOS 託管偏好設定 (MDM)。

高優先順序層會覆蓋低優先順序層中的普通標量值和列表值。表按鍵合並，而規則、鉤子和檔案系統限制等要求具有特定於欄位的組合行為。請使用 requirements.toml 參考瞭解當前架構，不要假定每個欄位都以相同方式合並。

為保持向後相容，受支援的本機客戶端會將舊版 approval_policy、approvals_reviewer 和 sandbox_mode 欄位重新解釋為要求。此轉換會在必要時新增相容選項；如需明確的允許列表，請使用 requirements.toml。

雲端託管要求

當用戶通過受支援套餐的 ChatGPT 登入時，受支援的本機客戶端 可以接收管理員強制執行的工作區相關要求。這是 與 requirements.toml 相容的策略的分發渠道。它不會授予 工作區存取權限，也不會取代工作區 RBAC。身份驗證要求必須 在本機管理。

開啟託管設定 以建立並分配雲端託管的要求。例如，以下策略會限制 審批和沙箱選項，並在支援的 shell 入口點 執行前提示：

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 登入時，客戶端會先檢查是否存在有效且身份匹配的快取條目。如果沒有可用的有效條目，客戶端會重試取得適用的設定包，並在成功後寫入已簽名的快取條目。如果請求失敗或超時，且沒有可用的有效快取，雲設定包載入會傳回錯誤，而不是在沒有云端託管要求層的情況下靜默啟動。

快取解析完成後，客戶端會將雲端要求與上述其他要求層組合。後臺重新整理可以更新快取，供以後啟動時使用；它不會替換當前程序中已經載入的要求。

確認管理員和員工體驗

為每項託管策略指定負責人，記錄哪些使用者或群組應 接收該策略，並說明實施任何檔案系統、網路、 審批或權限設定檔限制的業務原因。

在擴大推出範圍之前，請讓一名有代表性的使用者測試一項獲准的工作流程和一項有意 禁止的工作流程。請在受支援的客戶端中驗證實際生效的設定， 不要假定僅憑工作區角色或群組就能強制實施本機限制。

在本機管理身份驗證

將 allowed_login_methods、allowed_chatgpt_workspaces、 cli_auth_credentials_store 和 chatgpt_base_url 設定在本機系統的 requirements.toml 或 macOS MDM 要求中。Codex 會忽略 雲端受管要求中的這四個欄位。本機身份驗證要求會在 載入憑據及 Codex 取得雲端策略之前生效。

要強制通過 ChatGPT 登入到獲准的工作區，並將憑據儲存在 作業系統憑據儲存中，請使用以下設定：

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

allowed_login_methods 接受 chatgpt、api，或同時接受兩者。如果省略此設定， 則不限制登入方式。如果設定此項，列表中必須至少包含一種方式。 api 允許 API 身份驗證，包括 Amazon Bedrock。 工作區限制也適用於 Codex 存取令牌。

使用者設定的 forced_login_method 和 forced_chatgpt_workspace_id 必須 遵守這些要求。使用者選擇的工作區也必須出現在 受管工作區允許列表中。如果沒有匹配的工作區，ChatGPT 登入將 不可用。在允許的情況下，API 身份驗證仍然可用。如果沒有可用的登入 方式，Codex 將拒絕啟動。

有關憑據儲存模式和服務 URL 設定，請參閱要求參考 中的說明。

requirements.toml 範例

以下範例會阻止 --ask-for-approval never 和 --sandbox danger-full-access（包括 --yolo）：

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

此處，untrusted 保留了基於 trust_level = "untrusted" 派生的更嚴格審批行為；這並不意味著 approval_policy = "untrusted" 成為受支援的顯式設定。

停用 Appshots

要為託管使用者停用 Appshots，請設定頂層 allow_appshots 要求：

allow_appshots = false

在 Appshots 可用的環境中，allow_appshots = false 會將其停用。如果省略該鍵，要求不會約束 Appshots，並會應用正常的產品可用性檢查。通過 configRequirements/read 讀取有效要求的應用伺服器客戶端會收到與 allowAppshots 相同的限制；省略 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。

僅當所有託管客戶端都執行支援此功能的版本後，才使用下面的權限設定檔範例。在客戶端群升級完成前，請勿部署託管自定義設定檔。

該表存在時，表示允許使用的完整設定檔列表。設為 true 的設定檔會被允許，省略或設為 false 的設定檔會被拒絕，包括未來 Codex 版本中新增的內建設定檔。

允許標準設定檔

此策略允許只讀存取和工作區存取，但不允許完全存取：

default_permissions = ":workspace"

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

新增託管的最小權限預設設定

管理員可以在同一要求來源中定義自定義設定檔。請使用不會與使用者已載入設定中的名稱衝突的組織專用設定檔名稱。自定義名稱不能以 : 開頭，也不能使用保留名稱 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" is intentionally omitted, so it is denied.

[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  # Not honored because cloud requirements set this to false.

將 default_permissions 明確設定為允許的設定檔。如果省略該值，則僅當 :workspace 和 :read-only 均被明確允許時，本機執行時才預設使用 :workspace。如果不存在 allowed_permission_profiles，託管要求不會限制使用者可以選擇的設定檔名稱。每個條目都必須指定內建設定檔，或在已載入的設定或要求來源中定義的自定義設定檔。請在託管要求中定義自定義設定檔，以便集中控制其行為。

按主機覆蓋沙箱要求

當同一託管策略需要在不同主機上應用不同的沙箱要求時，請使用 [[remote_sandbox_config]]。例如，可以對筆記型電腦保持更嚴格的預設設定，同時允許匹配的開發機器或 CI 執行器寫入工作區。主機專用條目目前僅覆蓋 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 allowed

allowed_web_search_modes = [] 僅允許 "disabled"。例如，即使在 danger-full-access 會話中，allowed_web_search_modes = ["cached"] 也會阻止即時 Web 搜尋。

設定網路存取要求

當管理員需要集中定義網路存取要求時，請在 requirements.toml 中使用 [experimental_network]。這些要求與使用者的 features.network_proxy 開關相互獨立：無需啟用該功能標誌也能設定沙箱 網路，但如果當前沙箱仍關閉網路，它們不會授予命令網路 存取權限。將 experimental_network.enabled = true 設定為啟用託管代理；僅設定域名 規則不會啟用代理。

[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.domains] 中定義了管理員所有的 "allow" 條目，並希望這些規則具有排他性時，才使用 experimental_network.managed_allowed_domains_only = true。如果該值為 true，但沒有託管允許規則，則使用者新增的域名允許規則將不再 生效。請勿將規範的 domains 對映與舊版 allowed_domains 或 denied_domains 列表結合使用。

*.example.com 僅匹配子域名。**.example.com 匹配根 域名及其子域名。如果拒絕規則匹配，則其優先順序高於允許規則。

域名語法、本機/私有目標規則、拒絕優先於允許的行為以及 DNS 重繫結限制，與智能體審批與安全中所述的沙箱網路行為相同。

該代理路由在沙箱內執行的本機命令。瀏覽器工具 在存取 origin 前也會檢查託管網路拒絕規則和排他性允許列表； 這是單獨的策略檢查，並不會通過命令代理路由瀏覽器流量。 它不會過濾網頁搜尋、應用和連接器、MCP 伺服器、原生應用流量、Codex 服務請求或 Codex 雲端流量。 請針對各個介面使用相應的控制項：

• 使用 allowed_web_search_modes 限制網頁搜尋。
• 使用 features.apps = false 停用應用和連接器整合，並在支援的情況下使用 features.plugins = false 停用外掛。
• 使用託管的 mcp_servers 核准列表限制 MCP 伺服器。
• 使用 browser_use、in_app_browser 和 computer_use 等功能要求限制瀏覽器和 Computer Use 功能。
• 在 Codex 雲端環境設定中設定 Codex 雲端網路存取權限。

命令域名允許列表不能取代這些針對特定功能的 控制項。

控制瀏覽器和 Computer Use

使用 [browser_use] 和 [computer_use] 表，在 requirements.toml 中 限制受支援的桌面客戶端。請在部署所使用的客戶端版本 和作業系統上驗證該策略。設定允許規則不會 安裝外掛、授予作業系統權限，也不會審批仍需 審查的操作。

對於瀏覽器存取，請設定 origin 策略。origin 包括協議、 主機和可選埠，例如 https://example.com 或 https://*.example.com:8443。請勿包含路徑、查詢或片段。與 命令網路域名規則不同，瀏覽器 origin 規則會區分 HTTP 與 HTTPS， 並匹配埠。

以下範例將瀏覽器存取限制為已核准的網站，並禁止在該網站上傳 以及使用完整的 Chrome DevTools Protocol (CDP) 存取權限：

[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"

匹配的 origin 規則按欄位解析。如果拒絕規則匹配，則其優先順序最高；否則， 預設 origin 策略會為匹配規則未指定的欄位提供值。 本機設定可以增加限制，但無法放寬託管拒絕規則。 網路拒絕規則和排他性託管網路允許列表仍然適用。

將 browser_use.disable_auto_review = true 設定為停用瀏覽器操作的自動審批 審查，或在 origin 策略中設定 auto_review = "deny"， 以對該 origin 加以限制。這會控制審批處理方式，但不會 停用模型安全監控。

對於原生應用，請設定預設存取策略並指定允許的應用。例如， 以下 macOS 策略允許使用 Calculator，並禁止儲存審批：

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

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

Windows 策略可以通過 computer_use.windows.aumids 識別打包應用，或通過 computer_use.windows.exes 識別執行檔。執行檔規則必須包含 publisher_name、 product_name 和 access；binary_name 可選。請使用應用經過驗證的 身份，而不要只使用其顯示名稱。

有關完整欄位，請參閱設定參考； 有關託管 macOS 裝置的資訊，請參閱鎖定使用限制。

固定功能標誌

還可以為接收託管 requirements.toml 的使用者固定功能標誌：

[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

對於執行時功能，請使用 config.toml 的 [features] 表中的規範功能鍵。本機執行時會規範化已識別的功能以滿足這些固定值，並拒絕對 config.toml 或設定檔功能設定進行衝突寫入。

• in_app_browser = false 停用內建瀏覽器窗格。
• in_app_updates = false 會在重啟時停用 ChatGPT 桌面應用自身的更新程式（在受支援的環境中）。它不會影響外部軟體包部署，也不會延長對舊版應用的支援。有關設定和發布指導，請參閱管理應用更新。
• browser_use = false 停用瀏覽器中的 Computer Use 以及 Browser Agent 可用性。
• browser_use_full_cdp_access = false 停用本機執行時中的完整 CDP 存取權限（包括 Browser Developer 模式），並阻止 ChatGPT 桌面應用啟用相應設定。
• browser_use_external = false 停用外部 Browser Use。
• computer_use = false 停用 Computer Use、Record & Replay 及相關安裝或設定流程。

如果省略這些鍵，策略將允許這些功能，但仍受正常的客戶端、平台和發布可用性限制。

限制鎖定狀態下的計算機操作

若要防止使用者在託管 Mac 上啟用鎖定使用， 請新增以下要求：

[computer_use]
allow_locked_computer_use = false

此要求會移除用於啟用鎖定使用的控制項。如果鎖定使用已經啟用， 它不會將其關閉。如果省略此要求，則仍按正常的產品 可用性和使用者的本機設定執行。

設定自動審查策略

使用 allowed_approvals_reviewers 要求或允許自動審查。將其設為 ["auto_review"] 可要求自動審查；如果使用者可以選擇手動審批，請包含 "user"。

設定 guardian_policy_config 可替換自動審查策略中特定於租戶的部分。本機執行時仍會使用內建的複核者模板和輸出契約。託管 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.
"""

強制執行拒絕讀取要求

管理員可以使用 [permissions.filesystem] 拒絕讀取確切路徑或 glob 模式。使用者無法通過本機設定削弱這些要求。

[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.
]

存在拒絕讀取要求時，本機執行時會拒絕完全存取權限，並將本機執行限制在只讀或工作區沙箱中，以便強制執行這些要求。在原生 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"

注意：

• 本機執行時會強制執行 requirements.toml 中的鉤子設定，但不會分發 managed_dir 中的指令碼。
• 請使用 MDM 或裝置管理解決方案交付這些指令碼。
• 託管鉤子命令應引用已設定託管目錄下的絕對指令碼路徑。
• allow_managed_hooks_only = true 會跳過使用者、專案、會話和外掛來源中的鉤子，但仍會載入 requirements.toml 和其他託管設定層中的鉤子。

從要求中強制執行命令規則

管理員還可以使用 [rules] 表，從 requirements.toml 強制執行限制性命令規則。這些規則會與常規 .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 伺服器，請新增 mcp_servers 核准列表。對於 stdio 伺服器，按 command 匹配；對於可流式傳輸的 HTTP 伺服器，按 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 匹配。結構化命令規則仍不會檢查 cwd、env 或 env_vars。外掛捆綁的 MCP 伺服器在 plugins.<plugin>.mcp_servers.<server> 下使用相同的身份格式。

如果 mcp_servers 存在但為空，本機客戶端會停用所有 MCP 伺服器。

控制外掛可用性

要在受支援的本機客戶端中關閉外掛，請在 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，還會進行精確匹配。主機模式是與小寫 Git 主機名匹配的正規表示式；使用 ^ 和 $ 可匹配整個主機名。本機規則要求使用絕對且規範化的路徑。有關完整架構和合並行為，請參閱 requirements.toml 參考。

這些要求會拒絕不匹配的市場新增、外掛安裝以及 已設定的 Git 市場重新整理操作。它們還會在執行時篩選已設定的 市場及其外掛。

OpenAI 精選的 Git 市場（包括 API key 目錄）也必須 匹配來源允許列表。要允許這些市場，請新增以下 Git 來源， 且不設定 ref 限制：

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

要排除精選目錄，請省略該來源，並確保沒有範圍更廣的主機 規則允許它。內建外掛和遠端安裝的工作區外掛 不屬於此精選 Git 來源策略的管控範圍。

這些來源限制僅適用於支援外掛市場操作的本機客戶端：桌面應用中的 ChatGPT 和 Codex，以及 Codex CLI。它們不控制 ChatGPT Web 版或移動版中的外掛使用，也不會向 IDE 擴充套件新增外掛。

託管預設值 (managed_config.toml)

託管預設值用於設定受支援的本機客戶端啟動時採用的設定。客戶端 啟動時，這些預設值會覆蓋使用者的本機 config.toml 以及所有 CLI --config 覆蓋項。使用者在當前執行期間仍可更改這些設定，而客戶端下次 啟動時會再次應用預設值。

如果託管預設設定、macOS MDM 設定描述檔案或已儲存的設定為使用 ChatGPT 登入的 Codex 使用者 固定使用 gpt-5.5，請在 2026 年 10 月 14 日之前將其替換為 gpt-5.6-sol。GPT-5.5 將於該日從所有套餐的 ChatGPT、 ChatGPT Work 和 Codex 下線。OpenAI API 不受 影響。請參閱工作區模型可用性。

如果託管預設值、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 覆蓋項應用於基礎設定，但託管層會覆蓋它們。這意味著即使提供了本機標誌，每次執行仍會從託管預設值開始。

雲端 config.toml 使用常規設定優先順序， 而非上述舊版順序。雲端 requirements.toml 使用 要求優先順序。

位置

• 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)，優先順序遵循上述雲端託管要求順序。要求側的同一 [features] 表也可在 requirements_toml_base64 中使用；同樣應使用規範功能鍵。

MDM 設定工作流程

本機執行時遵循標準 macOS MDM 負載，因此可以使用 Jamf Pro、Fleet 或 Kandji 等工具分發設定。一個輕量級部署流程如下：

1. 建置託管負載 TOML，並使用 base64 編碼（不換行）。
2. 將該字串放入 MDM 設定檔的 com.openai.codex 域中，位置為 config_toml_base64（託管預設值）或 requirements_toml_base64（要求）。
3. 推送設定檔，然後讓使用者重啟受支援的本機客戶端，並確認啟動設定摘要反映了託管值。
4. 撤銷或更改策略時，請更新託管負載；客戶端會在下次啟動時讀取重新整理的偏好設定。

請避免在負載中嵌入機密或頻繁變化的動態值。請像對待其他受變更控制的 MDM 設定一樣對待託管 TOML。

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

建議的防護措施

• 對大多數使用者，建議使用帶審批的 workspace-write；僅在受控容器中授予完全存取權限。
• 保持 network_access = false，除非安全審查允許使用收集器或工作流程所需的域名。
• 使用託管設定固定 OTel 設定（匯出器、環境），但應保持 log_user_prompt = false，除非策略明確允許儲存提示內容。
• 定期審計本機 config.toml 與託管策略之間的差異以發現漂移；託管層應優先於本機標誌和檔案。