受管理的設定

受管理的設定可控制 ChatGPT 桌面版應用程式、Codex CLI 和 IDE 擴充功能中，涵蓋範圍內各項功能所支援的本機執行階段行為。支援的要求可能因用戶端和版本而異。受管理的設定不會授予 ChatGPT 工作區存取權、指派席位，也不會取代工作區的角色型存取控制 (RBAC)。如需管理工作區功能的存取權，請參閱角色與工作區權限；如需管理本機執行階段政策，請參閱本頁。

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

• 要求：由管理員強制執行、使用者無法覆寫的限制。
• 組態預設值：由系統或雲端管理、使用者可以覆寫的 config.toml 設定。
• 舊版受管理的預設值：支援的用戶端啟動時套用的 managed_config.toml 初始值。使用者仍可在執行期間變更設定；用戶端下次啟動時會重新套用這些預設值。

設定外掛程式市集與預設值

在系統 config.toml 或受管理的設定中的 config.toml 區段，定義本機或 Git 市集與外掛程式預設值。 這些設定是預設值，並非強制執行的政策。

如需組態鍵，請參閱組態參考資料； 如需覆寫規則，請參閱組態優先順序； 如需專案層級的組態，請參閱程式碼庫外掛程式設定。 工作區 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。 請在使用者層級的 ~/.codex/config.toml 中， 將該專案項目設為 trust_level = "untrusted"，並在 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" 成為 支援的明確設定。

停用應用程式快照

若要為受管理的使用者停用應用程式快照，請設定頂層的 allow_appshots 要求：

allow_appshots = false

在提供應用程式快照的環境中，allow_appshots = false 會停用此功能。如果 省略此鍵，要求就不會限制應用程式快照，並會套用一般產品 可用性檢查。App Server 用戶端若透過 configRequirements/read 讀取實際生效的要求，會以 allowAppshots 接收相同的限制；allowAppshots 若省略或值為 null，則不會停用 應用程式快照。

停用裝置遠端控制

若要為受管理的使用者停用裝置遠端控制， 請設定頂層的 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。主機名稱比對僅用於選取政策；請勿 將其視為裝置已通過驗證的證明。

您也可以限制網頁搜尋模式：

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

allowed_web_search_modes = [] 僅允許 "disabled"。 例如，allowed_web_search_modes = ["cached"] 會阻止即時網頁搜尋，即使在 danger-full-access 工作階段中也一樣。

設定網路存取要求

若管理員需要集中定義網路存取要求，請使用 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 重新繫結的限制，均與 智慧體核准與安全性中所述的沙盒網路行為相同。

代理伺服器會路由在沙盒內執行的本機指令所產生的流量。瀏覽器工具 也會在存取來源前，檢查受管理的網路拒絕規則及排他性允許清單； 這是獨立的政策檢查，並非將瀏覽器流量路由至 指令代理伺服器。它不會篩選網頁搜尋、應用程式與連接器、MCP 伺服器、 原生應用程式流量、Codex 服務請求或 Codex 雲端流量。 請使用各功能介面專屬的控制設定：

• 使用 allowed_web_search_modes 限制網頁搜尋。
• 使用 features.apps = false 停用應用程式與連接器整合，並在支援的情況下 使用 features.plugins = false 停用外掛程式。
• 使用受管理的 mcp_servers 核准清單限制 MCP 伺服器。
• 使用 browser_use、in_app_browser 和 computer_use 等功能要求，限制瀏覽器與電腦操作能力。
• 在 Codex 雲端的雲端環境設定中，設定其網路存取權。

指令的網域允許清單無法取代這些針對特定能力的 控制設定。

控管瀏覽器與電腦功能

使用 requirements.toml 中的 [browser_use] 和 [computer_use] 表格， 限制支援的桌面用戶端。請在部署環境採用的用戶端版本 與作業系統上驗證政策。設定允許規則並不會 安裝外掛程式、授予作業系統權限，或核准 仍須審查的動作。

若要控管瀏覽器存取權，請設定來源政策。來源包含通訊協定、 主機及選填的連接埠，例如 https://example.com 或 https://*.example.com:8443。請勿包含路徑、查詢或片段。 瀏覽器來源規則與指令網路的網域規則不同，會區分 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"

符合條件的來源規則會逐欄位判定。符合條件的拒絕設定優先； 其餘未由符合條件的規則指定的欄位，則由預設來源政策補足。 本機組態可以增加限制，但不能放寬受管理的拒絕設定。 網路拒絕規則及排他性的受管理網路允許清單仍然適用。

設定 browser_use.disable_auto_review = true 可停用瀏覽器動作的自動核准審查， 或在來源政策中設定 auto_review = "deny"， 針對該來源加以限制。這項設定控管的是核准處理方式；它不會 停用模型安全監控。

對於原生應用程式，請設定預設存取政策，並指定允許的應用程式。 例如，這項 macOS 政策允許使用「計算機」，並禁止儲存核准：

[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 會停用瀏覽器中的電腦功能，並使瀏覽器智慧體無法使用。
• browser_use_full_cdp_access = false 會停用本機執行環境中的完整 CDP 存取權， 包括瀏覽器開發人員模式，並防止 ChatGPT 桌面版應用程式 啟用對應設定。
• browser_use_external = false 會停用外部瀏覽器功能。
• computer_use = false 會停用電腦、錄製與重播，以及相關的 安裝或設定流程。

若省略這些鍵，政策就會允許這些功能，但實際可用性仍取決於用戶端、 平台及功能推出狀況。

限制鎖定時使用電腦

若要防止使用者在受管理的 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 或端點管理工具 安裝所參照指令碼的目錄。

若要在使用者已於本機關閉掛勾的情況下仍強制執行受管理掛勾， 請在設定 [hooks] 的同時固定設定 [features].hooks = true。若要略過使用者、專案、工作階段 與外掛程式的掛勾，同時仍允許受管理掛勾，請設定 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 和其他 受管理組態層中的掛勾。

透過要求強制執行指令規則

管理員也可以在 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 伺服器，請新增 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 金鑰登入 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 金鑰目錄）也必須 符合來源允許清單。若要允許這些市集，請加入下列 Git 來源， 且不要設定 ref 限制：

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

若要排除精選目錄，請省略該來源，並確認沒有範圍更廣的主機 規則允許該來源。隨附的外掛程式與遠端安裝的工作區外掛程式 不屬於此精選 Git 來源政策的範圍。

這些來源限制僅適用於支援外掛程式市集操作的本機用戶端： 桌面 App 中的 ChatGPT 和 Codex，以及 Codex CLI。 它們不會控制網頁版或行動版 ChatGPT 的外掛程式使用情況，也不會 為 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 金鑰進行驗證的 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. 撤銷或變更政策時，請更新受管理的承載資料；用戶端 會在下次啟動時讀取更新後的偏好設定。

避免在承載資料中嵌入機密資訊或頻繁變動的動態值。請將受管理的 TOML 視為其他 MDM 設定一樣，納入變更管控。

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 與受管理政策之間的差異，以發現組態偏離；受管理的層級應優先於本機旗標和檔案。