托管配置

托管配置用于控制 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 与托管策略之间的差异以发现漂移；托管层应优先于本地标志和文件。