受管設定
向受支援的本機客戶端分發設定預設值並強制執行要求
受管設定允許企業管理員為 ChatGPT Work 和 Codex 設定受支援的要求和預設值。要求用於限制使用者和任務可執行的操作。預設值提供初始設定值。支援情況取決於產品、客戶端版本和執行環境。
對於支援雲端管理的設定,請先進入管理控制台中的智能體安全。使用設定控制項執行常見任務,或選擇以 TOML 編輯 來檢視、複製或編輯設定文字。兩個檢視編輯的是同一策略; TOML 還提供了沒有專用控制項的受支援欄位。使用雲端管理的設定無需分發本機檔案。身分驗證限制和裝置管理的部署有單獨的本機設定流程。
企業管理員可以通過以下方式控制受支援的本機客戶端行為:
要求:由管理員強制執行、使用者無法覆蓋的約束。
設定預設值:由系統或雲端管理、使用者可以覆蓋的
config.toml設定。舊版受管預設值:受支援的客戶端啟動時應用的
managed_config.toml初始值。使用者仍可在執行期間更改設定。客戶端會在下次啟動時重新應用這些預設值。
有關 Global 基線、環境覆蓋以及編排器和執行器的欄位列表,請參閱 Agent Security。
在智能體安全中設定策略
在已啟用智能體安全的工作區中,工作區所有者、工作區管理員以及擁有 Codex 管理員權限的成員可以管理策略。擁有策略編輯器的存取權限並不意味著成員可以使用策略所控制的功能。
使用工作區預設值 設定工作區基線。當特定使用者、群組或角色需要不同設定時,使用覆蓋項。受眾覆蓋項用於選擇策略的適用物件;環境設定用於選擇受支援的執行控制的適用環境。
- 開啟管理控制台 > 智能體安全,然後選擇工作區預設值 或 覆蓋項 下要編輯的策略。
- 開啟要求 以設定強制限制,或開啟預設值 以設定成員 可以在這些限制內更改的初始值。
- 將核准、網頁搜尋及其他智能體整體設定保留在全域 中。如果 相關卡片提供新增環境設定,可使用該選項新增 本機環境 或 Codex 雲端環境,以設定受支援的執行 設定。空的環境文件會繼承全域設定;它不會複製或 固定當前基線。
- 使用本指南中介紹的控制項。對於高階欄位,選擇
以 TOML 編輯,然後編輯相應作用域的
requirements.toml或config.toml。選擇使用設定控制項 可傳回視覺化編輯器。 - 檢視驗證訊息,然後選擇儲存更改。在 規則編輯器中應用規則會更新草稿;這本身並不會儲存策略。
- 按照確認管理員和員工體驗 中的說明,檢查策略選擇和受支援的客戶端行為。
環境編輯器和受支援的欄位取決於工作區和策略。將全域設定移入環境之前,請參閱設定的適用範圍。全域中的設定不一定適用於每個產品或執行路徑。
複製或複用設定
視覺化編輯器並不取代 TOML。選擇以 TOML 編輯 可複製設定、保留參考副本,或在另一策略中複用設定。選擇使用設定控制項 可切換回視覺化編輯器。
- 開啟源策略,然後選擇以 TOML 編輯。
- 選擇要複製的作用域:全域 或可用的環境選項卡。
根據要複用的內容,複製要求(
requirements.toml)、預設值 (config.toml)或兩者中的文字。 - 開啟目標策略,選擇以 TOML 編輯,然後選擇匹配的
作用域。將要求貼上到
requirements.toml,將預設值貼上到config.toml。替換文字之前,請檢視目標策略中的現有設定; 保留仍應適用的其他設定。 - 檢視驗證訊息以及目標策略的適用物件和優先順序, 然後選擇儲存更改。在依賴複製的策略之前, 請確認最終的客戶端行為。
複製的文字包含為該策略和作用域編寫的設定。它不包含分配關係、策略順序、其他環境文件,也不包含結合其他策略和裝置設定後得到的有效設定。如有需要,請單獨複製環境設定。切換檢視或複製文字不會儲存策略更改。
試用以下範例:更改一項設定,然後選擇以 TOML 編輯 以檢視其設定。使用使用設定控制項 切換回原檢視,繼續嘗試。
範例策略
更改一項範例設定,然後切換檢視,以 TOML 形式檢視同一設定。
要求 · 全域
allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only"]
allowed_web_search_modes = ["disabled"]
僅供演示。更改僅保留在此頁面中,不會更新工作區。最近更改的欄位會在 TOML 檢視中突出顯示。
選擇合適的控制項
| 任務 | 設定位置 | 更改內容 |
|---|---|---|
| 限制瀏覽器和原生應用存取 | 要求 > 桌面功能可用性、站點規則 和應用規則 | 控制哪些受支援的桌面功能可用,以及這些功能可以存取哪些站點或應用。 |
| 限制核准、沙箱或網頁搜尋選項 | 要求 > 策略護欄 | 限制受支援客戶端可用的選項。 |
| 設定核准、權限、搜尋或工具行為的初始值 | 預設值 | 設定成員可以在強制要求範圍內更改的值。 |
| 限制命令的網路目標 | 要求 > 網路使用控制 | 將受管網路規則應用於受支援的命令流量。這不是工作區範圍的網際網路開關。 |
| 設定外掛和受管鉤子 | 以 TOML 編輯 | 用於設定沒有專用視覺化控制項的受支援策略欄位。 |
| 在登入前限制登入方式或工作區 | 本機系統要求或 macOS MDM | 在載入雲端策略之前應用身分驗證限制。 |
控制瀏覽器和 Computer Use
使用管理控制台中的智能體安全 來管理受支援桌面客戶端的瀏覽器和原生應用存取權限。請先使用 UI 控制項。以下 TOML 範例為通過檔案分發策略以及需要使用 TOML 編輯器的設定提供設定參考。
Browser Use 控制智能體在瀏覽器中的活動。Computer Use 控制智能體在原生桌面應用中的活動。內建瀏覽器窗格的設定與 Browser Use 相互獨立。請參閱瀏覽器工作階段和現有登入狀態,瞭解各瀏覽器存取路徑之間的區別。
開始之前
使用有權管理智能體安全策略的帳戶。確認策略的適用人員,以及需要支援的客戶端版本和作業系統。請參閱智能體安全,瞭解策略分配、全域設定和受支援的環境覆蓋項。
使用要求 設定使用者無法覆蓋的限制。預設值 用於設定這些限制範圍內的初始值。允許某個站點或應用並不會安裝外掛、授予作業系統權限、讓使用者登入,也不會核准仍然需要審查的操作。
在桌面功能可用性 下,檢查瀏覽器使用、外部瀏覽器使用 和電腦使用。強制關閉 會停用相應功能;站點或應用的允許規則無法覆蓋此設定。請單獨檢查完整 CDP 存取權限;禁止使用者主動啟用 會阻止使用者啟用該功能。
這些桌面控制項不會設定託管的 Work Cloud 瀏覽器。請在管理控制台 > 權限與角色 > 工作區功能 > 雲端電腦功能 下分別管理雲端瀏覽器使用 和雲端網路存取。參閱 Agent Security 如何應用於 Work Cloud。
設定瀏覽器存取權限
- 開啟管理控制台 > Agent Security。使用工作區預設值 設定 工作區的基準策略,或在覆蓋設定 下開啟相關策略。在 要求 中,轉到桌面瀏覽器控制。
- 在站點規則 中,開啟預設 行的操作選單,然後選擇編輯預設規則。 若要將存取範圍限制為已核准的站點,請將站點存取權限 設為阻止,然後 選擇應用規則。當匹配的站點規則將某項設定 保留為使用預設規則 時,該設定採用預設 行提供的值。
- 選擇新增站點規則。在站點或模式 中,輸入一個源:包含協議方案、
主機名和可選埠。例如,
https://example.com有效;https://example.com/files無效。不要包含路徑、查詢參數或片段。 HTTP 和 HTTPS 屬於不同的源。如果埠與 協議方案的預設埠不同,請指定埠。 - 設定站點存取權限,並檢查下載、上傳 和除錯/CDP。 根據需要選擇允許 或阻止,或將設定保留為使用預設 規則。除錯/CDP 控制用於瀏覽器 除錯的完整 Chrome DevTools Protocol 存取權限。選擇允許 後,仍會繼續執行常規策略和核准檢查。
- 檢查該站點的自動審查、始終允許 和核准有效期。 核准有效期 提供本輪對話 和當前對話執行緒 兩個選項。同時檢查桌面 瀏覽器控制 中的瀏覽器歷史記錄、儲存站點核准記錄 和自動核准請求 設定。
- 選擇新增規則,檢查驗證訊息,然後選擇儲存更改。 在接收該策略的受支援客戶端上,測試一個允許存取的站點和一個被阻止的站點。請分別測試 上傳、下載和其他受限操作。
停用瀏覽器操作的自動審查後,這些操作會轉交使用者核准。這不會停用模型安全監控。
當多個源模式匹配時,每項設定均以最嚴格的值為準。本機設定無法放寬受管策略中的拒絕設定。受管網路拒絕規則和排他性允許列表也適用於瀏覽器工具。有關源模式,參閱瀏覽器策略欄位,其中還介紹了核准行為。
電腦使用功能還可以將瀏覽器作為原生應用操作。瀏覽器使用功能的站點和功能規則不適用於這種方式。請單獨檢查原生應用存取權限;參閱瀏覽器安全邊界。
設定原生應用存取權限
- 在要求 中,轉到桌面應用控制 > 應用規則。
- 使用預設 行的操作選單,為沒有匹配 規則的應用設定存取權限。若要將電腦使用功能限制為僅可操作已核准的應用,請預設阻止存取,並為 這些應用新增允許規則。
- 選擇新增應用規則。在編輯規則 對話方塊中,從應用 中選擇 macOS bundle ID、 Windows AUMID 或 Windows 執行檔。對於 bundle ID 或 Application User Model ID (AUMID),請輸入準確的應用 識別符。對於 Windows 執行檔,請輸入發布者名稱 和產品名稱;二進位檔名 為 可選項。請使用經過驗證的應用身分資訊,而非顯示名稱或檔案路徑。
- 設定規則的應用存取權限,然後選擇新增規則。檢查桌面應用控制 下的儲存應用 核准記錄,檢查驗證訊息,然後 選擇儲存更改。停用儲存核准記錄後,仍可授予僅在當前 工作階段中有效的核准;允許儲存核准記錄並不代表核准某個應用。
- 在部署中每個受支援的作業系統上,測試一個允許存取的應用和一個被阻止的應用。 確認作業系統權限仍然適用,且使用者仍須提供必要的核准。
有關 Windows 身分要求,請參閱電腦使用策略欄位;有關受管 Mac 的限制,請參閱鎖定狀態下的使用限制說明。
檢查實際生效的策略
如果允許存取的站點或應用仍被阻止,請檢查其他匹配的規則、策略分配和優先順序、裝置要求以及使用者設定。某個來源中的允許規則無法繞過其他適用的拒絕規則。參閱要求的位置和優先順序。
如果某項設定未生效,請確認客戶端、作業系統和策略分發途徑均支援該設定。對於具有本機電腦存取權限的 Work Cloud,請特別留意:某些欄位僅獲得部分支援,或需要驗證。參閱設定參考中的 Work 相容性說明。
當使用者無法存取某項功能或所需外掛時,請分別檢查工作區權限和外掛控制設定。
TOML 設定參考
以下範例在 requirements.toml 中表達了相同的策略意圖。通過檔案或 TOML 編輯器管理策略時,可參考這些範例。使用 Agent Security 中的控制項時,無需編輯本機檔案。
此瀏覽器範例預設拒絕存取,允許存取 https://example.com,禁止在該站點上傳和進行完整 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",以限制該來源的自動審查。
要為符合條件的 Enterprise 工作區啟用站點工具,請設定 browser_use.allow_webmcp = true。此受管啟用設定適用於桌面應用的內建瀏覽器。將其設為 false 或省略該設定時,仍會執行常規的功能可用性檢查;false 不會強制阻止該功能。使用者偏好設定和站點權限仍然適用。
此原生應用範例允許使用 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 為可選項。
有關所有受支援的欄位和值,請參閱requirements.toml 參考。要停用某項能力,而非限制個別站點或應用,請參閱固定功能開關。
其他桌面控制項
以下桌面控制項涵蓋功能可用性、Locked Use、Appshots 和裝置遠端控制。使用專用設定管理功能可用性和 Locked Use;通過以 TOML 編輯 設定 Appshots 和裝置遠端控制。有關桌面應用流量的目標地址限制,請參閱控制桌面應用的網路目標地址。
固定功能開關
對於 Agent security 中提供的桌面功能,開啟全域 > 要求 > 桌面功能可用性。將應用內瀏覽器、瀏覽器使用、外部瀏覽器使用 或電腦使用 設為強制關閉 以停用相應能力,然後選擇儲存更改。對於完整 CDP 存取,選擇阻止使用者啟用,以防止使用者啟用它。允許某項功能並不會覆蓋其產品、平台或發布範圍方面的可用性限制。
對於其他受支援的功能開關,使用以 TOML 編輯 和全域 requirements.toml 文件,或受支援的本機要求來源。以下範例包含執行時和桌面專用功能的固定設定:
[features]
hooks = 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 或設定檔中的功能設定寫入衝突值。
受管設定 unified_exec = false 會保留命令執行能力,但會停用可恢復程序和 write_stdin 工具。使用者設定無法停用此功能。
in_app_browser = false停用內建瀏覽器窗格。in_app_updates = false會在重啟後停用 ChatGPT 桌面應用自身的更新程式, 適用於支援此設定的平台。它不會影響外部軟體包部署,也不會 延長對舊版應用的支援。有關設定和推出指南,請參閱 管理應用更新。browser_use = false停用受支援的 Browser Use 能力。外部 Browser Use 和原生應用 Computer Use 各有獨立的控制項。browser_use_full_cdp_access = false停用本機 執行時中的完整 CDP 存取,包括瀏覽器開發者模式,並阻止 ChatGPT 桌面 應用啟用相應設定。browser_use_external = false停用通過 受支援的瀏覽器擴充套件由智能體執行的 Browser Use。computer_use = false停用原生應用 Computer Use,包括將 瀏覽器作為原生應用進行操作,以及 Record & Replay 和相關安裝或 設定流程。
僅停用 Browser Use 並不能阻止所有瀏覽器操作途徑。 原生應用 Computer Use 在該能力和應用存取權限均獲准時,仍可操作瀏覽器;Browser Use 的站點和能力規則不適用於這一途徑。要阻止這一途徑,請將電腦使用 設為強制關閉(computer_use = false),或者,如果需要保留其他原生應用的可用性,請在應用規則中拒絕瀏覽器應用。請分別檢查外部瀏覽器使用 和應用內瀏覽器。有關各途徑適用的控制項,請參閱瀏覽器工作階段和現有登入狀態。
如果省略這些鍵,策略會允許這些功能,但仍受常規客戶端、平台和發布範圍方面的可用性限制。
限制鎖定狀態下的電腦使用
要防止使用者在受管 Mac 上啟用 Locked Use,請開啟全域 > 要求 > 桌面應用控制項,將允許在鎖定時使用 設為已停用,然後選擇儲存更改。此設定不會關閉 Mac 上已啟用的 Locked Use。
在 TOML 編輯器或通過裝置管理分發時,等效的要求如下:
[computer_use]
allow_locked_computer_use = false此要求會移除用於啟用 Locked Use 的控制項。它不會關閉已啟用的 Locked Use。如果省略此要求,常規的產品可用性限制和使用者的本機設定仍然適用。
停用 Appshots
Appshots 允許受支援的客戶端包含應用快照。要為雲端管理的使用者停用此功能,請在 Agent security 中開啟以 TOML 編輯,並設定全域 requirements.toml 中的頂層 allow_appshots 欄位。對於裝置管理的部署,請使用適用的本機要求來源:
allow_appshots = false在 Appshots 可用的情況下,allow_appshots = false 會將其停用。如果省略此鍵,要求不會限制 Appshots,而是執行常規的產品可用性檢查。通過 configRequirements/read 讀取生效要求的 App-server 客戶端會以allowAppshots 的形式收到相同限制;省略 allowAppshots 或將其值設為 null 不會停用 Appshots。
停用裝置遠端控制
要為雲端管理的使用者停用裝置遠端控制,請在 Agent security 中使用以 TOML 編輯,並設定全域 requirements.toml 中的頂層 allow_remote_control 欄位。你還可以在受支援的本機要求來源中設定 allow_remote_control:
allow_remote_control = false在支援裝置遠端控制的情況下,allow_remote_control = false會將其停用。如果省略此鍵,要求不會限制裝置遠端控制,而是執行常規的產品可用性檢查。此要求不會停用 SSH 遠端連線。
設定核准和執行權限
使用本節設定核准行為、權限邊界和初始預設值。先從策略護欄和預設值開始。後續任務會說明強制指定審查者、自訂權限設定檔、檔案系統限制、主機覆蓋設定和命令規則的 TOML 要求。
管理員強制執行的要求 (requirements.toml)
要求用於約束安全敏感設定(核准策略、核准審查者、自動審查策略、沙箱模式、權限設定檔、網頁搜尋模式、受管鉤子、使用者可啟用的 MCP server,以及可使用的外掛市場來源)。解析設定時(例如來自 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 部分。
設定核准、沙箱和網頁搜尋護欄
使用要求 > 策略護欄 限制受支援客戶端可選擇的選項。這些控制項用於約束設定,並不設定初始值。請在預設值 下單獨設定初始值。
- 在全域 中,開啟核准策略 並選擇允許的核准 方式。例如,按需詢問 允許智能體針對沙箱提權等 操作請求核准。從不詢問 會禁止核准 請求,但不會授予不受限制的執行權限。
- 開啟沙箱模式 以限制舊版沙箱選項。唯讀 限制
寫入,工作區寫入 允許在工作區和設定的
可寫根目錄內寫入,完全存取 則移除檔案系統沙箱限制。對於
使用權限設定檔而非
sandbox_mode的部署,請使用 權限設定檔要求。 - 在全域 中,開啟網頁搜尋模式 以限制網頁搜尋。選擇快取 可允許使用快取搜尋而不允許即時搜尋,選擇停用 則關閉網頁 搜尋。網頁搜尋限制與命令網路規則相互獨立。
- 檢查允許的選項及其對應的預設值,然後選擇 儲存更改。
未設定某項要求時,該策略不會對其施加限制。其他適用策略仍然有效。對不受信任的命令詢問 選項對應要求允許列表中的 untrusted;它不會恢復已停用的顯式 approval_policy = "untrusted" 設定。對於這種情況,請遵循下方的遷移指南。
要限制網頁搜尋,請使用全域 > 要求 > 策略護欄 > 網頁搜尋模式。等效的 TOML 如下:
allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowedallowed_web_search_modes = [] 僅允許 "disabled"。例如,即使在 danger-full-access 工作階段中,allowed_web_search_modes = ["cached"] 也會阻止即時網頁搜尋。
設定預設值
預設值為成員提供初始設定。它們不會強制施加限制,也不會授予工作區功能的存取權限。
- 開啟策略的預設值 卡片。在全域 中設定適用於整個智能體的預設值; 使用可用的環境選項卡設定受支援的執行預設值。
- 在命令執行 下,選擇初始核准策略 和 核准審查者,以及適用的沙箱模式 或預設 權限。審查者決定預設由誰審查核准請求; 核准策略決定何時可以發起請求。
- 在網頁搜尋 下,選擇初始網頁搜尋 模式和網頁搜尋 上下文。在應用和工具 下,檢查受支援應用工具的應用/連接器、開放世界 工具 和破壞性工具 設定。
- 確認預設值滿足你的要求,然後選擇儲存更改。
對於沒有視覺化控制項的受支援預設值(例如外掛市場設定),請使用以 TOML 編輯。這些雲端預設值採用常規設定優先順序。它們不同於舊版 managed_config.toml 優先順序,後者在啟動時將託管預設值置於本機設定之上。
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"
成為受支援的顯式設定。
遷移已停用的 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 核准策略遷移以瞭解範例和安全權衡。
設定自動審查策略
要將自動審查設為預設值,請使用全域 > 預設值 > 命令執行 > 核准審查者。設定預設值後,使用者仍可選擇其他獲准的審查者。要強制使用自動審查或提供組織的稽核說明,請使用以 TOML 編輯,改為編輯全域requirements.toml。這些要求與瀏覽器的自動審查控制項相互獨立。
使用 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.
"""控制可用的權限設定檔
使用預設值 > 命令執行 > 預設權限 來選擇使用者初始使用的內建設定檔。要強制限制使用者可選擇的設定檔或定義自訂設定檔,請使用以 TOML 編輯,並在適用的全域範圍或受支援的執行環境範圍內設定 requirements.toml。僅選擇預設值不會限制可用的設定檔。
使用 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,受管要求不會限制使用者可以選擇的設定檔名稱。每個條目都必須指定內建設定檔,或在已載入的設定或要求來源中定義的自訂設定檔。請在受管要求中定義自訂設定檔,以便集中控制其行為。
強制實施禁止讀取要求
使用以 TOML 編輯,將檔案系統限制新增到適用的全域或受支援執行環境的 requirements.toml 中。這些限制會阻止讀取敏感路徑;僅設定唯讀預設值並不會隱藏檔案。
管理員可以使用以下設定,禁止讀取精確路徑或 glob 模式匹配的路徑:[permissions.filesystem]。使用者無法通過本機設定放寬這些要求。
[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 子程序的讀取不使用這條沙箱規則。
按主機覆蓋沙箱要求
在智能體安全中使用以 TOML 編輯 來編寫特定於主機的要求。環境控制項用於選擇執行環境;主機模式用於在受支援的執行時中選擇匹配的機器。
當同一受管策略需要在不同主機上應用不同的沙箱要求時,請使用 [[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。主機名匹配僅用於選擇策略;不要將其視為經過身分驗證的裝置證明。
強制實施要求中的命令規則
在智能體安全中使用以 TOML 編輯,將命令規則和 MCP server限制新增到全域 requirements.toml 中。命令規則為匹配的命令指定核准或拒絕決定;MCP 限制則約束客戶端可以啟用哪些伺服器身分。核准策略 控制項無法編寫這兩類規則集。
管理員還可以通過 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 server,請新增 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 server在以下位置使用相同的身分結構:plugins.<plugin>.mcp_servers.<server>。
如果 mcp_servers 存在但為空,本機客戶端會停用所有 MCP server。
設定網路存取
命令聯網和桌面應用聯網使用不同的控制項。首先使用網路使用控制 管理受支援的命令流量,檢查環境和執行時限制,然後按需使用獨立的桌面應用要求。瀏覽器站點規則仍位於控制瀏覽器和 Computer Use 中。
設定網路存取要求
在智能體安全中,使用要求 > 網路使用控制 來管理受支援的命令聯網。在全域 中設定共享基線,或在可用的本機環境 或 Codex Cloud 環境 選項卡中設定特定於環境的執行設定。
- 將託管網路 設為開啟,以將網域規則應用於託管命令的 流量。僅新增網域規則不會啟用託管代理。
- 在網路規則 下,選擇新增網路規則。輸入網域,例如
api.openai.com或**.example.com,不含 URL 協議方案或路徑。在存取權限 下選擇 允許 或拒絕,然後選擇儲存規則 以更新 草稿。對其他目標重複此操作。 - 如果使用者設定和逐網域核准不得擴大託管允許清單,請將 僅允許管理員新增的網域 設為開啟。新增 必需的允許條目;僅包含拒絕條目的列表不會允許存取其他目標。
- 對於需要本機監聽器或私有目標的工作流程,請檢查允許本機網路存取 設定。直接本機連線可能繞過代理的 網域規則。更改此設定前,請檢視下文的 Codex Cloud 連線 限制。
- 檢查繼承的規則和驗證訊息,然後選擇儲存更改。 在每個受影響的執行環境中,分別測試一個應成功的請求和一個應被阻止的 請求。
將託管網路 設為關閉 會清除該作用域中編寫的網路規則,並儲存明確的關閉值;這不會停用網際網路存取。未設定 會移除該作用域中編寫的網路設定,以便適用的策略或執行時預設值生效。移除環境設定可能使繼承的全域規則顯現。對於高階網路欄位或視覺化編輯器無法表示的現有舊版網域列表,請使用以 TOML 編輯。
當管理員需要集中定義網路存取要求時,請在 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 server、原生應用流量、Codex 服務請求或其他特定功能的流量。 請使用各功能對應的控制項:
- 使用
allowed_web_search_modes限制網頁搜尋。 - 使用
features.apps = false停用應用和連接器整合,並使用features.plugins = false在支援的環境中停用外掛。 - 使用受管的
mcp_servers核准列表限制 MCP server。 - 使用
browser_use、in_app_browser和computer_use等功能要求限制瀏覽器和電腦使用能力。 - 對於受支援的受管 Codex Cloud 命令,請分別設定 Agent Security 要求和 Cloud 環境的網際網路設定。
命令網域允許列表不能取代這些針對特定功能的 控制項。
在受支援的受管 Codex Cloud 執行路徑上,Agent Security 要求會約束命令的網路存取。Codex Cloud 環境的網際網路設定單獨生效。Agent Security 中允許的網域不會覆蓋 Cloud 環境網際網路設定中的限制。這些命令網路控制本身不會停用受管網頁搜尋、應用或 MCP。ChatGPT Work Cloud 有獨立的能力權限,不會繼承這些 Agent Security 要求。
受管命令允許列表適用於使用受管代理的命令。如果策略允許完全提升沙箱權限且已獲得核准,該次執行就可以繞過命令代理。範圍有限的網路授權與完全提升沙箱權限不同。請根據預期的管控邊界設定強制執行的核准和沙箱要求,並測試普通命令和提升權限後的命令。
沒有有效的允許目標: 當託管網路 和僅允許管理員新增的網域 均為開啟狀態時,普通託管命令需要有效的允許目標。如果未設定或繼承任何允許條目,這些命令就沒有可存取的目標。僅包含拒絕條目的策略不會隱式允許存取網際網路的其餘部分。儲存前,請新增必需的允許條目並檢查繼承的規則。此限制適用於託管命令代理,並非所有工具或已獲核准的完整沙箱提權執行。
Codex Cloud 本機/私有網路連線: 如果本機/私有網路連線被顯式設為關閉,即使目標網域已獲允許,也可能導致 Codex Cloud 無法連線其上游代理。請檢查最終的
allow_local_binding值,並確定該值由哪項策略或設定提供。在受支援的 Cloud 代理路徑上,只有當適用的要求、選定的網路設定檔和代理功能設定均未提供值時,此值才預設為 true。繼承的 false 仍視為顯式設定。在支援的環境中,可設定優先順序更高的 Cloud 覆蓋項,為 Codex Cloud 更改此值,同時不更改 Local 使用的 Global 值。這不會新增網域允許條目。在依賴此覆蓋項之前,請驗證執行器是否支援它。不要將此 Cloud 預設值應用於 Local。
當環境要求為空時,全域要求生效。將託管網路 設為關閉 與 Cloud 環境的網際網路存取設定相互獨立。有關執行作用域的詳細資訊,請參閱 Agent Security 執行控制。
網路策略優先順序和執行時限制
在給定策略內,優先順序從高到低依次為:特定作業系統的環境覆蓋 → 所有作業系統的環境覆蓋 → 全域。優先順序較高的策略始終優先於優先順序較低的策略,即使後者更具體。某些要求具有特定於欄位的合併規則。隨後,執行時會強制執行解析後的要求。請將下文中特定於欄位的網路情況與策略優先順序分開考慮。
這些範例比較同一策略內的環境設定和全域設定,前提是已設定託管網路,且沒有優先順序更高的策略更改這些值。範例說明了特定於欄位的合併行為和執行時行為。
按環境設定不同的網域存取權限
對於同一策略中的同一網域規則,管理員的環境覆蓋可以允許全域設定中拒絕的網域,也可以拒絕全域設定中允許的網域。如果沒有環境覆蓋,則繼承全域規則。其他有效的拒絕規則或存取控制仍可能阻止請求。
網域規則如何合併
| 全域規則 | 環境規則 | 網域策略結果 |
|---|---|---|
| 拒絕 | 允許 | 由環境覆蓋允許,但須滿足下述條件。 |
| 允許 | 拒絕 | 在該環境中被阻止。 |
| 允許 | 允許 | 由這些網域規則允許。 |
| 拒絕 | 拒絕 | 被這些網域規則阻止。 |
| 允許或拒絕 | 無覆蓋 | 繼承全域規則。 |
這些結果比較同一策略中的同一網域鍵,前提是沒有優先順序更高的策略更改結果。優先順序較高的值會替換同一個鍵的值。其他繼承的鍵保持不變。允許規則不會繞過另一條匹配的拒絕規則,例如繼承的萬用字元規則。空的環境對映不會清除繼承的規則。
範例: 在全域設定中拒絕 packages.example.com,並在開發環境中允許該網域。滿足上述條件時,開發環境可以允許存取該網域。除非被覆蓋,否則生產環境會繼承全域的拒絕規則。
確認已部署的執行器支援這些合併規則。常規託管執行器的支援範圍仍需驗證。
Orchestrator 限制。雲端執行時不支援託管 HTTP/SOCKS 監聽埠和非迴環代理監聽器;套接字規則的支援情況取決於執行路徑。下表中的本機執行設定並不屬於受支援的 Orchestrator 設定。
其他網路執行時限制
下列所有欄位名均位於 experimental_network 中,所屬檔案為 requirements.toml。箭頭表示同一策略內的全域值及其後的環境值。這些本機執行案例並不能證明 Orchestrator 支援相同的設定。
| 設定及嘗試的覆蓋 | 執行時行為 | 管理員操作 |
|---|---|---|
| domains: deny → allow | 在受支援的路徑上,環境的允許規則會替換同一個全域網域鍵的值。其他匹配的拒絕規則仍然適用。 | 在已部署的執行器上測試允許的請求和被阻止的請求。 |
managed_allowed_domains_only: true → false |
不要根據網域鍵的合併方式推斷排他性行為。當有效設定為 enabled = true 和 managed_allowed_domains_only = true 時,普通命令需要有效的允許條目。 |
檢查有效設定和繼承的允許條目。僅包含拒絕條目的策略不會允許存取網際網路的其餘部分。 |
allow_local_binding: false → true |
在受支援的 Codex Cloud 代理路徑上,明確的 false 值可能阻止存取上游代理。受支援的更高優先順序 Cloud 覆蓋可以更改此值。 | 檢查有效值的來源以及執行器的支援情況。不要將 Cloud 預設值應用於 Local。 |
代理啟用、排他性、上游代理行為和 Unix 套接字規則的行為因執行器而異。不要將網域鍵的合併方式推廣到這些設定。請驗證有效值,並測試已部署的執行時。有關 Codex Cloud 本機/私有連線的資訊,請參閱設定網路存取要求。
推出前驗證行為
測試工作流程實際使用的目標、本機監聽器、代理行為和套接字路徑。在每個受影響的環境中,分別檢查一個應成功的操作和一個應被阻止的操作。確認已部署的執行時版本支援你使用的每項設定。
控制桌面應用的網路存取目標
使用 Agent security 中的以 TOML 編輯,在全域設定中設定這些桌面端專用的要求。網路使用控制 介面管理命令網路存取,後者屬於獨立的策略。
使用 [application.network](位於 requirements.toml 中)來限制桌面
應用的網路存取目標。設定 enabled = true 後,外部請求必須使用
HTTPS 或 WSS,並且必須精確匹配值為 "allow" 的網域,該網域需在
[application.network.domains] 中設定。子網域不會被自動允許。空的
網域對映不允許存取任何外部目標。有關支援的鍵,請參閱設定
參考。
此策略獨立於命令網路存取規則和瀏覽器源規則。它 不會限制原生模組或派生程序的存取目標, 也不管控 Work Cloud 的執行。
設定外掛和託管鉤子
執行這些任務時,請使用 Agent security 中的以 TOML 編輯 或受支援的本機設定源。市場預設設定、強制外掛限制和託管鉤子的用途各不相同;請選擇與你所需策略相符的任務。
設定外掛市場和預設設定
使用 Agent security > 以 TOML 編輯,在全域 config.toml 文件中定義本機或 Git 市場以及外掛預設設定。你也可以通過系統 config.toml 分發這些設定。它們提供初始市場和外掛設定,並非強制執行的策略。要限制成員可以使用的來源,請設定市場來源要求。
有關設定鍵,請參閱設定參考,有關覆蓋規則,請參閱設定優先順序,有關專案級設定,請參閱儲存庫外掛設定。工作區 GitHub 匯入和同步是獨立的功能。
控制外掛可用性
使用 Agent security 中的以 TOML 編輯,在全域 requirements.toml 中設定強制執行的外掛功能設定,或通過本機要求將這些設定分發給受裝置管理的客戶端。預設設定 > 應用和工具 > 應用/連接器 用於設定應用工具的預設值;它並非強制執行的 features.plugins 開關。有關工作區外掛權限,請參閱應用和連接器。
要在受支援的本機客戶端中關閉外掛,請在 requirements.toml 中將 features.plugins 設為 false:
features.plugins = false當使用者使用 API key 登入 Codex 時,此設定同樣適用。有關受支援的設定,請參閱 features.plugins 參考。
限制外掛市場來源
使用 以 TOML 編輯 在全域requirements.toml 中設定市場來源要求,或通過本機要求下發這些要求。這些規則限制使用者可以新增和使用哪些本機或 Git 來源。它們獨立於市場預設設定。
要限制外掛市場來源,請設定
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 擴充套件新增外掛。
通過要求強制執行託管鉤子
託管鉤子會在受支援的任務或工具事件發生時執行管理員定義的操作。在“智能體安全”中使用 以 TOML 編輯,在全域requirements.toml 中設定這些鉤子;設定控制項不包含專用的鉤子編輯器。以下執行路徑決定了哪些鉤子類型可以執行。
啟用託管策略和遠端鉤子後,具有本機存取權限的 Work Cloud 和 dots 會在雲端編排器上使用管理員管理的遠端 MCP 鉤子。在全域 requirements.toml 中設定 mcp_tool 處理程序。沒有本機存取權限的 Work Cloud 和個人帳戶不使用這些企業鉤子。雲端編排不支援命令/shell、提示詞和智能體處理程序;來自本機設定、外掛或本機目錄的鉤子;環境範圍的鉤子;以及 SessionEnd MCP 鉤子,即使工具在本機執行也是如此。當編排和執行均在本機進行時,現有受支援的鉤子仍可在純本機的 Work 和 Codex 執行緒中執行。管理員仍可在“智能體安全”中為這些工作流程設定受支援的託管鉤子。
在依賴這些鉤子之前,請測試回呼連通性、所需事件和失敗時的行為。受支援的顯式拒絕可以阻止操作,但 PreToolUse 回呼出錯、超時或回應格式錯誤可能導致鉤子失敗,卻不會阻止工具執行。MCP 鉤子不提供完整的 Compliance API 稽核記錄。以下指令碼和目錄範例仍僅適用於 Codex。
管理員也可以直接在 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及其他 託管設定層中的鉤子。
瞭解策略範圍和優先順序
通過本節瞭解策略的適用範圍、要求的合併方式、客戶端如何接收雲端託管設定,以及如何驗證結果。
對於具有本機存取權限的 Work 和 dots,啟用託管策略後,受支援的全域策略會約束共享的雲端編排器;適用的本機執行要求則約束所連線的電腦。Work 雲容器保留現有的 Work Cloud 策略,受支援的裝置控制仍適用於本機執行。Codex 保持現有的設定行為。託管設定不會授予工作區席位或功能存取權限。請通過角色和工作區權限管理這些權限。
智能體安全與 Work Cloud 本機電腦存取
使用管理控制台中的“智能體安全”管理策略和設定。它取代了“策略與設定”。“智能體安全”可在管理控制台中使用,獨立於 Work Cloud 本機電腦存取功能。現有策略、分配關係和排序均予以保留。請在“智能體安全”中檢查現有策略。Work Cloud 本機電腦存取功能需要單獨選擇啟用。有關遷移指導,請參閱智能體安全。
將策略自動化遷移到 智能體安全 之前:
確定受影響的整合。清點用於更新策略的 Terraform 設定和指令碼,並記錄它們管理的策略。
使用策略 API 管理全域設定。要管理本機或 Codex Cloud 設定,請使用“智能體安全”介面。現有的全域 API 工作流程在遷移後仍可使用。測試指令碼和 Terraform 整合,並確認策略分配關係和排序保持不變。
進行必要的更改並測試自動化。驗證預期更新已應用於正確的“智能體安全”策略,且相應控制措施已強制執行。
策略遷移不會授予 Work 或 dots 本機電腦存取權限。建議在推出前檢查或建立策略,但確認流程並不要求先建立策略才能啟用存取。在啟用 允許本機電腦存取 之前,請檢查遷移後的基線;如果當前僅通過 MDM 下發策略,則請建立雲端基線。如果任一雲端策略啟用了 enforce_residency,Work 和 dots 的 允許本機電腦存取 都將被停用。此保護措施不會設定工作區的資料駐留位置,也不會單獨停用 Work Cloud 或 dots。
環境覆蓋可在策略內針對不同環境調整受支援的設定。在給定策略中,優先順序從高到低依次為:特定作業系統的環境覆蓋 → 所有作業系統的環境覆蓋 → 全域。高優先順序策略始終優先於低優先順序策略,即使低優先順序策略更具體也是如此。某些要求具有特定於欄位的合併規則。請確認工作區中可用的覆蓋編輯器和欄位。
啟用託管策略和遠端鉤子後,具有本機存取權限的 Work Cloud 和 dots 會在雲端編排器上使用管理員管理的遠端 MCP 鉤子。在全域 requirements.toml 中設定 mcp_tool 處理程序。沒有本機存取權限的 Work Cloud 和個人帳戶不使用這些企業鉤子。雲端編排不支援命令/shell、提示詞和智能體處理程序;來自本機設定、外掛或本機目錄的鉤子;環境範圍的鉤子;以及 SessionEnd MCP 鉤子,即使工具在本機執行也是如此。當編排和執行均在本機進行時,現有受支援的鉤子仍可在純本機的 Work 和 Codex 執行緒中執行。管理員仍可在“智能體安全”中為這些工作流程設定受支援的託管鉤子。在依賴這些鉤子之前,請測試回呼連通性、所需事件和失敗時的行為。受支援的顯式拒絕可以阻止操作,但 PreToolUse 回呼出錯、超時或回應格式錯誤可能導致鉤子失敗,卻不會阻止工具執行。MCP 鉤子不提供完整的 Compliance API 稽核記錄。請參閱設定參考。
位置和優先順序
對於本機執行,要求按以下順序從低優先順序到高優先順序應用。此順序也適用於 Work Cloud 本機電腦存取中的本機步驟:
- 系統
requirements.toml(在 Unix 系統上為/etc/codex/requirements.toml, 包括 Linux 和 macOS;在 Windows 上為%ProgramData%\OpenAI\Codex\requirements.toml)。 - 通過雲端設定包下發的“智能體安全”要求。
- 本機客戶端重新解釋為要求的舊版
managed_config.toml欄位。 - 通過以下鍵下發的 macOS 託管偏好設定(MDM):
com.openai.codex:requirements_toml_base64。
優先順序較高的設定層會覆蓋較低設定層中的普通標量值和列表值。表按鍵合併,而規則、鉤子和檔案系統限制等要求則具有特定於欄位的組合行為。請查閱requirements.toml 參考以瞭解當前架構,不要假定每個欄位都以相同的方式合併。
為保持向後相容,受支援的本機客戶端會將舊版approval_policy、approvals_reviewer 和 sandbox_mode 欄位重新解釋為要求。此轉換會在必要時新增相容性選項;如需顯式指定允許列表,請使用requirements.toml。
Work Cloud 本機電腦存取的優先順序
對於具有本機存取權限的 Work 和 dots,請區分全域編排器策略與執行策略。適用的本機要求約束所連線的電腦。Work 雲容器和 dots 雲電腦使用各自的執行設定和要求,而非其他執行器使用的託管環境包。
對於本機執行,MDM 和舊版受管裝置要求的優先順序高於 Agent Security。裝置的系統要求檔案優先順序低於 Agent Security。在每項策略內,先解析特定於作業系統的環境覆蓋設定,再解析適用於所有作業系統的環境覆蓋設定,最後解析 Global。跨策略比較時,策略優先順序高於設定的具體程度。
| 控制項 | 不啟用同步的本機 Work 和本機 Codex | 通過 Work Cloud 存取本機電腦 |
|---|---|---|
| 企業要求 | 遵循上述本機要求優先順序。 | 適用於本機執行器。Work 雲容器保留現有的 Work Cloud 策略。 |
| 裝置執行限制 | 由受支援的本機控制措施強制執行。 | 遵循上述本機要求優先順序,包括優先順序高於 Agent Security 的 MDM 和舊版要求。 |
| 環境覆蓋設定 | 使用相關產品的設定模型。 | 在同一策略內:先應用特定於作業系統的環境覆蓋設定,再應用適用於所有作業系統的環境覆蓋設定,最後應用 Global。低優先順序策略無法憑藉更具體的設定獲得優先權。 |
要求用於施加約束,設定預設值則提供初始值。對於具有本機存取權限的 Work 和 dots,啟用受管策略後,受支援的 Global 策略通過共享的雲端編排器生效。適用的本機 requirements.toml 要求控制已連線電腦上的執行。Work 雲容器和 dots 雲電腦使用各自的執行設定和要求,而非其他執行器類型使用的受管環境設定包。本機執行限制不會自動應用於這些雲電腦。請檢查雲端功能權限,並分別測試本機執行和雲端執行。
將核准和網頁搜尋等編排器控制項保留在 Global 中。如果提供了專用的“允許的核准策略”和“允許的網頁搜尋模式”控制項,請使用這些控制項;其他受支援的欄位則使用 TOML 設定。欄位列表和執行範圍請參閱設定參考。
雲端託管的要求
當使用者通過受支援套餐的 ChatGPT 登入時,受支援的本機客戶端可以接收與工作區關聯、由管理員強制執行的要求。這是相容 requirements.toml 的策略分發渠道。它不會授予工作區存取權限,也不會取代工作區 RBAC。身分驗證要求必須在本機管理。
使用 Agent security 控制項設定常見要求。對於僅允許 on-request 核准以及 read-only 或 workspace-write 沙盒的策略,請使用 核准策略 和沙盒模式,這兩項位於策略護欄 下。若還要在受支援的 shell 入口點執行前提示核准,請使用以 TOML 編輯,將 [rules]表新增到 Global 的 requirements.toml 中。
完整的等效 TOML 設定如下:
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 參考。
本機客戶端如何應用雲端託管的要求
下面介紹的本機載入和快取行為適用於受支援的本機客戶端。這些說明並未確定:對於使用 Work Cloud 本機電腦存取功能且已在執行的任務,更改後的雲端策略何時生效。在依賴更改後的限制之前,請驗證實際生效的策略。
當使用者啟動受支援的本機客戶端,並通過受支援套餐的 ChatGPT 登入時,客戶端會先檢查是否存在有效且與身分匹配的快取條目。如果沒有有效條目,客戶端會取得適用的設定包,並在失敗時重試,成功後寫入帶簽名的快取條目。如果請求失敗或超時,且沒有可用的有效快取,雲端設定包載入會傳回錯誤,而不會在缺少雲端託管要求層的情況下靜默啟動。
快取解析完成後,客戶端會將雲端要求與上述其他要求層合併。背景重新整理會更新快取的設定包,使其可用於後續設定載入。這並不保證已在執行的任務會立即使用更改後的策略。某些桌面端設定需要重啟應用;請按照重啟提示操作,並在依賴更改後的設定之前驗證實際生效的設定。
確認管理員和員工體驗
為每項受管策略指定一名負責人,記錄應接收該策略的使用者或組,並記錄任何檔案系統、網路、核准或權限設定檔限制的業務原因。
使用具有目標權限的使用者帳號,分別測試一個允許的工作流程和一個被阻止的工作流程。在受支援的客戶端中檢查實際生效的設定。僅有工作區角色或組並不能強制實施本機執行時限制。
使用 Agent security 中的測試策略,檢查哪些策略與所選的成員、組或角色匹配。在可編輯工作階段中,此操作會檢查當前草稿,而不會儲存它。結果顯示的是策略選擇情況,而非最終合併的設定,也不表明客戶端是否強制執行某項限制。儲存後,請在每個相關客戶端和執行路徑上測試允許的工作流程和被阻止的工作流程。
部署裝置託管的設定
使用本機系統要求或 MDM 設定身分驗證限制和裝置託管策略。舊版 managed_config.toml 機制的啟動優先順序與 Agent security 的預設值 不同。MDM 工作流程同時涵蓋要求和舊版預設值。
在本機管理身分驗證
在本機系統的要求設定中設定 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 設定。
受管預設值(managed_config.toml)
對於受支援的雲端託管初始值,請使用 Agent security 預設值進行設定。本節介紹舊版裝置託管的managed_config.toml 機制及其不同的啟動優先順序。在 Agent security 中編輯預設值 不會將 managed_config.toml 檔案部署到成員的裝置上。
受管預設值用於設定受支援的本機客戶端啟動時採用的設定。客戶端
啟動時,這些預設值會覆蓋使用者的本機 config.toml 以及所有 CLI --config
覆蓋項。使用者在當前執行期間仍可更改這些設定,而客戶端下次
啟動時會再次應用預設值。
GPT-5.5 將於 2026 年 10 月 14 日太平洋夏令時間中午 12 點(19:00 UTC)
在通過 ChatGPT 登入的 Codex 中停用。如果受管預設值、macOS MDM 設定檔
或已儲存的設定為這些使用者固定了 gpt-5.5,請將其替換為可用模型。
管理員為受影響的使用者啟用 gpt-6.1-sol 後,請選擇該模型。
OpenAI API 及使用 API key 認證的 Codex 工作階段不受影響。請參閱
工作區模型可用性。
對於仍固定使用 gpt-5.4 或 gpt-5.4-mini 的設定,請遵循
GPT-5.4 遷移指南。
請確保受管預設值符合要求;本機執行時會拒絕不允許的值。
優先順序與分層
本機執行時按以下順序組裝有效設定(上層覆蓋下層):
- 受管偏好設定(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
如果檔案不存在,本機執行時會跳過受管層。
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與託管策略之間的差異,以發現設定偏移;託管層應優先於本機標誌和檔案。
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 等工具分發設定。一個輕量級部署流程如下:
- 建置受管負載 TOML,並使用
base64編碼(不換行)。 - 將該字串放入 MDM 設定檔的
com.openai.codex域中,位置為config_toml_base64(受管預設值)或requirements_toml_base64(要求)。 - 推送設定檔,然後讓使用者重啟受支援的本機客戶端,並確認啟動設定摘要反映了受管值。
- 撤銷或更改策略時,請更新受管負載;客戶端會在下次啟動時讀取重新整理的偏好設定。
請避免在負載中嵌入敏感資訊或頻繁變化的動態值。請像對待其他受變更控制的 MDM 設定一樣對待受管 TOML。