受管配置

受管配置允许企业管理员为 ChatGPT Work 和 Codex 设置受支持的要求和默认值。要求用于限制用户和任务可执行的操作。默认值提供初始设置值。支持情况取决于产品、客户端版本和执行环境。

对于具有本地访问权限的 Work 和 dots，启用受管策略后，受支持的 Global 策略控制共享的云端编排器；适用的本地执行要求控制已连接的计算机。Work 云容器保留现有的 Work Cloud 策略，受支持的设备控制仍适用于本地执行。Codex 保持现有的配置行为。受管配置不会授予工作区席位或功能访问权限。请使用角色与工作区权限管理这些权限。

企业管理员可以通过以下方式控制受支持的本地客户端行为：

• 要求：由管理员强制执行、用户无法覆盖的约束。

• 配置默认值：由系统或云端管理、用户可以覆盖的 config.toml 设置。

• 旧版受管默认值：受支持的客户端启动时应用的 managed_config.toml 初始值。用户仍可在运行期间更改设置。客户端会在下次启动时重新应用这些默认值。

有关 Global 基线、环境覆盖以及编排器和执行器的字段列表，请参阅 Agent Security。

Agent Security 与通过 Work Cloud 访问本地计算机

使用管理控制台中的 Agent Security 管理策略和配置。它将取代“策略与配置”。Agent Security 将向所有用户开放，不受是否启用通过 Work Cloud 访问本地计算机的影响。现有策略、分配和排序均会保留。请在 Agent Security 中检查现有策略。通过 Work Cloud 访问本地计算机需要单独选择启用。有关迁移指导，请参阅 Agent Security。

将策略自动化迁移到 智能体安全（Agent Security） 前：

1. 确定受影响的集成。盘点用于更新策略的 Terraform 配置和脚本，并记录它们管理的策略。

2. 使用策略 API 管理 Global 设置。要管理 Local 或 Codex Cloud 设置，请使用 Agent Security 界面。迁移后，现有的 Global API 工作流仍然可用。请测试脚本和 Terraform 集成，并确认策略分配和排序保持不变。

3. 进行必要的更改并测试自动化流程。验证预期更新是否应用到正确的 Agent Security 策略，并确认相应的控制措施得到执行。

策略迁移不会为 Work 或 dots 授予本地计算机访问权限。建议在推出前检查或创建策略，但确认流程并不要求先创建策略才能启用访问权限。在启用允许访问本地计算机 前，请检查迁移后的基线；如果目前仅通过 MDM 下发策略，请创建云端基线。如果任一云策略启用了 enforce_residency，Work 和 dots 的允许访问本地计算机 都会被禁用。这项保护措施不会配置工作区的数据驻留，也不会单独禁用 Work Cloud 或 dots。

环境覆盖可在同一策略内针对不同环境调整受支持的设置。在同一策略内，优先级从高到低依次为：特定操作系统的环境覆盖 → 所有操作系统的环境覆盖 → Global。较高优先级的策略仍会优先于较低优先级的策略，即使后者的设置更具体。某些要求具有特定于字段的合并规则。请确认你的工作区可用的覆盖编辑器和字段。

启用受管策略和远程钩子后，具有本地访问权限的 Work Cloud 和 dots 会在云端编排器上使用管理员管理的远程 MCP 钩子。在 Global requirements.toml 中配置 mcp_tool 处理程序。不具有本地访问权限的 Work Cloud 和个人账号不会使用这些企业钩子。云端编排不支持命令/shell、提示词和智能体处理程序；来自本地配置、插件或本地目录的钩子；环境范围的钩子；以及 SessionEnd MCP 钩子，即使工具在本地执行也是如此。当编排和执行均在本地进行时，现有的受支持钩子仍可在仅本地运行的 Work 和 Codex 聊天中使用。管理员仍可在 Agent Security 中为这些工作流配置受支持的受管钩子。在依赖这些钩子前，请测试回调连通性、所需事件和失败时的行为。受支持的明确拒绝响应可以阻止操作，但 PreToolUse 回调错误、超时或格式错误的响应可能导致钩子失败，而不阻止工具执行。MCP 钩子不提供完整的 Compliance API 审计记录。请参阅配置参考。

配置插件市场和默认值

在系统 config.toml 中定义本地或 Git 市场及插件默认值， 或在 智能体安全（Agent Security） 中使用受支持的配置默认值进行定义。 这些设置是默认值，并非强制执行的策略。

有关配置键，请参阅配置参考； 配置优先级 介绍了覆盖规则，仓库插件设置 介绍了项目级配置。工作区 GitHub 导入与 同步是单独的功能。

管理员强制执行的要求 (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 部分。

迁移已停用的 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 审批策略迁移 中的说明。

位置和优先级

对于本地执行，要求按以下顺序从低到高的优先级应用。此顺序也适用于通过 Work Cloud 访问本地计算机时执行的本地步骤：

1. 系统 requirements.toml（在 Unix 系统上为 /etc/codex/requirements.toml， 包括 Linux 和 macOS；或使用 %ProgramData%\OpenAI\Codex\requirements.toml， 适用于 Windows）。
2. 通过云端配置包下发的 Agent Security 要求。
3. 本地客户端重新解释为要求的旧版 managed_config.toml 字段。
4. 通过以下键下发的 macOS 受管偏好设置（MDM）： com.openai.codex:requirements_toml_base64。

高优先级层会覆盖低优先级层中的普通标量值和列表值。表按键合并，而规则、钩子和文件系统限制等要求具有特定于字段的组合行为。请使用 requirements.toml 参考了解当前数据结构，不要假定每个字段都以相同方式合并。

为保持向后兼容，受支持的本地客户端会将旧版 approval_policy、approvals_reviewer 和 sandbox_mode 字段重新解释为要求。此转换会在必要时添加兼容选项；如需明确的允许列表，请使用 requirements.toml。

通过 Work Cloud 访问本地计算机时的优先级

对于具有本地访问权限的 Work 和 dots，请区分 Global 编排器策略与执行策略。适用的本地要求控制已连接的计算机。Work 云容器和 dots 云计算机使用各自的执行配置和要求，而非其他执行器使用的受管环境配置包。

对于本地执行，MDM 和旧版受管设备要求的优先级高于 Agent Security。设备的系统要求文件的优先级低于 Agent Security。在每项策略内，先解析特定操作系统的环境覆盖设置，再解析适用于所有操作系统的环境覆盖设置，最后解析 Global。跨策略比较时，策略优先级高于设置的具体程度。

要求用于施加约束，配置默认值则提供初始值。对于具有本地访问能力的 Work 和 dots，启用受管策略后，受支持的 Global 策略通过共享云编排器生效。适用的本地 requirements.toml 要求约束已连接计算机上的执行。Work 云容器和 dots 云计算机使用各自的执行配置和要求，而不是其他执行器类型使用的受管环境配置包。本地执行限制不会自动应用于这些云计算机。请检查云端功能权限，并分别测试本地执行和云端执行。

将审批和网页搜索等编排器控制项保留在 Global 中。在可用时，使用专用的“允许的审批策略”和“允许的网页搜索模式”控制项，其他受支持的字段则使用 TOML。有关字段列表和执行范围，请参阅配置参考。

网络策略优先级和运行时限制

在给定策略内，优先级从高到低依次为：特定操作系统的环境覆盖设置 → 适用于所有操作系统的环境覆盖设置 → Global。高优先级策略仍然优先于低优先级策略，即使低优先级策略的设置更具体。部分要求具有字段特定的合并规则。运行时随后强制实施解析后的要求。请将下文针对特定字段的网络情形与策略优先级分开考虑。

这些示例比较同一策略内的环境设置和 Global 设置，前提是已配置受管网络，且没有更高优先级的策略更改这些值。它们说明了针对特定字段的合并行为和运行时行为。

按环境设置不同的域名访问权限

对于策略内的同一域名规则，管理员设置的环境覆盖可以允许 Global 中拒绝的域名，也可以拒绝 Global 中允许的域名。如果没有环境覆盖设置，则继承 Global 规则。其他生效的 Deny 规则或访问控制仍可能阻止请求。

域名规则如何合并

这些结果比较同一策略内的同一域名键，前提是没有更高优先级的策略更改结果。更高优先级的值会替换同一键的值。其他继承的键保持不变。Allow 不会绕过其他匹配的 Deny 规则，例如继承的通配符规则。空的环境映射不会清除继承的规则。

示例： 在 Global 中拒绝 packages.example.com，并在 Development 中允许它。在满足上述条件时，Development 可以允许访问。Production 会继承 Global 的 Deny 规则，除非存在覆盖设置。

确认已部署的执行器支持这些合并规则。常规受管执行器的支持范围仍需验证。

编排器限制。云端运行时不支持受管 HTTP/SOCKS 监听端口和非回环地址的代理监听器；套接字规则的支持情况取决于执行路径。下表中的本地执行设置不属于受支持的 Orchestrator 配置。

其他网络运行时限制

下文所有字段名均位于 experimental_network 下，所属文件为 requirements.toml。箭头前后分别表示同一策略内的 Global 值和环境值。这些本地执行情形不能证明 Orchestrator 支持相同设置。

代理启用、排他性、上游代理行为和 Unix 套接字规则的行为因执行器而异。不要将域名键的合并方式推广到这些设置。请验证生效值，并测试已部署的运行时。有关 Codex Cloud 的本地/私有网络连接，请参阅配置网络访问要求。

推出前验证行为

测试工作流实际使用的目标地址、本地监听器、代理行为和套接字路径。在每个受影响的环境中，分别检查一项应成功的操作和一项应被阻止的操作。确认已部署的运行时版本支持你使用的每项设置。

云端受管要求

当用户通过受支持套餐的 ChatGPT 登录时，受支持的本地客户端 可以接收管理员强制执行的工作区相关要求。这是 与 requirements.toml 兼容的策略的分发渠道。它不会授予 工作区访问权限，也不会取代工作区 RBAC。身份验证要求必须 在本地管理。

在管理控制台中打开 智能体安全（Agent Security），以查看和管理云端 要求。对于现有策略，使用迁移后的全局基线。例如， 以下策略限制 审批和沙箱选项，并在受支持的 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 参考。

本地客户端如何应用云端受管要求

下文介绍的本地加载和缓存行为适用于受支持的本地客户端。这并不能确定更改后的云端策略何时会在使用 Work Cloud 本地计算机访问功能的运行中任务内生效。在依赖更改后的限制之前，请验证生效的策略。

当用户启动受支持的本地客户端，并在受支持的套餐中使用 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 重绑定限制，与智能体审批与安全中所述的沙箱网络行为相同。

代理负责路由在沙箱内运行的本地命令。浏览器工具 也会在访问源站前检查受管网络拒绝规则和排他性允许列表。 这是独立的策略检查，不会将浏览器流量路由到 命令代理。它不会过滤网页搜索、应用和连接器、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。

空的环境要求会继承 Global。关闭管理网络并不等同于关闭 Cloud 环境的互联网访问。请参阅在 UI 中配置网络。

控制浏览器和 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"

匹配的来源规则按字段分别解析。匹配的拒绝规则优先。 否则，匹配规则未指定的字段由默认来源策略提供。 本地配置可以增加限制，但不能放宽受管的拒绝规则。 网络拒绝规则和排他性的受管网络允许列表仍然适用。

将 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 子进程读取不使用此沙箱规则。

从要求中强制执行受管钩子

启用受管策略和远程钩子后，具有本地访问权限的 Work Cloud 和 dots 会使用云端编排器上由管理员管理的远程 MCP 钩子。请在 Global requirements.toml 中配置 mcp_tool 处理程序。没有本地访问权限的 Work Cloud 和个人账户不会使用这些企业钩子。云端编排不支持命令/shell、提示词和智能体处理程序；来自本地配置、插件或本地目录的钩子；限定于特定环境的钩子；以及 SessionEnd MCP 钩子，即使工具在本地执行也是如此。当编排和执行都在本地进行时，现有受支持的钩子仍可在仅限本地的 Work 和 Codex 聊天中正常工作。管理员仍可在 Agent Security 中为这些工作流配置受支持的受管钩子。

在依赖这些钩子之前，请测试回调连接、所需事件和失败时的行为。受支持的显式拒绝可以阻止操作，但 PreToolUse 回调错误、超时或格式错误的响应可能导致钩子失败，而不会阻止工具执行。MCP 钩子不提供完整的 Compliance API 审计记录。以下脚本和目录示例仍以 Codex 为适用范围。

管理员也可以直接在 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 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。

控制插件可用性

要在受支持的本地客户端中关闭插件，请在 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-6-sol 后，请选择该模型。GPT-5.5 将在当天从所有套餐的 ChatGPT、 ChatGPT Work 和 Codex 中停用。OpenAI API 不受影响。请参阅工作区模型可用性。

对于仍固定使用 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

如果文件不存在，本地运行时会跳过受管层。

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