受管理的設定

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

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

• 要求：管理員強制執行、使用者無法覆寫的限制。
• 受管理的預設值：受支援的用戶端啟動時套用的初始值。使用者仍可在執行期間變更設定；用戶端下次啟動時會重新套用受管理的預設值。

管理員強制執行的要求（requirements.toml）

要求會限制涉及安全性的設定，包括核准政策、核准審查者、自動審查政策、沙盒模式、權限設定檔、網頁搜尋模式、受管理的掛勾、使用者可啟用的 MCP 伺服器，以及使用者可新增、從中安裝外掛程式或重新整理的自訂外掛程式市集來源。解析組態時，例如從 config.toml、設定檔或 CLI 組態覆寫解析，如果某個值與強制規則衝突，本機用戶端會改用相容的值並通知使用者。如果設定 mcp_servers 允許清單，只有 MCP 伺服器的名稱和身分都符合已核准的項目時，用戶端才會啟用該伺服器；否則會將其停用。

要求也可以透過 requirements.toml 中的 [features] 資料表限制功能旗標。請注意，功能不一定涉及安全性，但企業可視需要固定其設定值。省略的鍵不受限制。

在 Codex 0.138.0 或更新版本中，請優先使用權限設定檔 搭配 allowed_permission_profiles 和受管理的 default_permissions。 allowed_sandbox_modes 僅適用於仍設定 sandbox_mode 的舊版部署。

如需完整的鍵清單，請參閱《組態參考資料》中的 requirements.toml 章節。

位置與優先順序

每個受支援的本機用戶端都會依優先順序由低到高整合要求：

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 登入時，用戶端會先檢查是否有有效且與身分相符的快取項目。 若沒有有效項目，用戶端會重試擷取適用的套件，成功後 寫入已簽署的快取項目。若請求失敗或逾時，且沒有可用的 有效快取，載入雲端組態套件時會傳回錯誤，而不會 在缺少雲端管理的要求層級時 逕自啟動。

完成快取解析後，用戶端會將雲端要求與 前述其他要求層級整合。背景重新整理可以更新 快取，供後續啟動時使用；但不會取代目前處理程序 已載入的要求。

確認管理員與員工的使用體驗

為每項受管理的政策指定負責人，記錄應接收該政策的使用者或群組， 並記載對檔案系統、網路、核准或權限設定檔施加限制的 業務理由。

擴大部署範圍前，請找一位具代表性的使用者，測試已核准的 工作流程和刻意禁止的工作流程。請確認受支援用戶端中實際生效的 設定，不要假設僅憑工作區角色或群組 即可強制執行本機限制。

requirements.toml 範例

此範例會封鎖 --ask-for-approval never 和 --sandbox danger-full-access（包括 --yolo）：

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

停用應用程式快照

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

allow_appshots = false

在應用程式快照可用時，allow_appshots = false 會停用這項功能。若 省略此鍵，要求便不會限制應用程式快照，並會套用一般的產品 可用性檢查。透過 configRequirements/read 讀取有效要求的 App Server 用戶端，會以 allowAppshots 接收相同的限制；若省略該欄位，或 null 為 allowAppshots 的值，均不會停用 應用程式快照。

停用裝置遠端控制

若要為受管理的使用者停用裝置遠端控制 功能，請設定頂層 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 的前提，是 :workspace 和 :read-only 都已明確獲准。當 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 工作階段中，也會阻止即時網頁搜尋。

設定網路存取要求

[experimental_network] 是 requirements.toml 中的設定，適用於管理員需要 集中定義網路存取要求的情境。這些要求與使用者的 features.network_proxy 切換設定彼此獨立：即使未啟用該功能旗標，仍可設定沙盒 網路；但如果目前使用的沙盒停用網路，這些要求不會授予指令網路 存取權。請設定 experimental_network.enabled = true，以啟用受管理的代理伺服器； 僅有允許清單不會讓代理伺服器生效。

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：您 同時定義由管理員控管的 allowed_domains，且希望該允許清單 具有排他性。如果設定為 true，但沒有受管理的允許規則，使用者新增的網域允許 規則將不再生效。

網域語法、本機／私人目的地規則、拒絕優先於允許的行為， 以及 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 的使用者：

[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

這項要求不會啟用電腦功能，只會禁止在 macOS 鎖定時使用該功能。如果省略這項要求，就不會限制鎖定時的使用；實際可用性仍取決於產品的一般提供狀況和使用者的本機設定。

設定自動審查政策

使用 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 和其他 受管理組態層中的掛勾。

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

管理員也可以在 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 伺服器。

控制外掛程式可用性

若要在支援的本機用戶端中停用外掛程式，請將 features.plugins 的值 設為 false，並將此設定放在 requirements.toml 中：

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 市集等作業。由 Codex 管理的 OpenAI 市集，只要其來源和保留名稱相符，仍可使用。這些要求不會在執行階段篩選已設定的使用者市集或其中的外掛程式。

這些來源限制僅適用於支援外掛程式市集作業的本機用戶端：桌面 App 中的 ChatGPT 和 Codex，以及 Codex CLI。這些限制不會控制網頁版或行動版 ChatGPT 中的外掛程式使用情況，也不會為 IDE 擴充功能新增外掛程式。

受管理的預設值（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 金鑰驗證的 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），優先順序則遵循 上述雲端管理要求的順序。要求端使用的同一個 [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 與受管理政策之間的差異，以偵測設定漂移；受管理的設定層應優先於本機旗標和檔案。