托管配置

企业管理员可以通过两种方式控制本地 Codex 行为：

要求限制 security-sensitive 设置（批准策略、批准审核者、自动审核策略、沙箱模式、权限 配置文件 、Web 搜索模式、托管挂钩以及用户可以启用的 MCP 服务器（可选））。解析配置时（例如从 config.toml、 配置文件 或 CLI 配置覆盖），如果值与强制规则冲突，Codex 将回退到兼容值并通知用户。如果您配置 mcp_servers 白名单，则仅当 MCP 服务器的名称和身份均与批准的条目匹配时，Codex 才会启用 MCP 服务器；否则，Codex 将禁用它。

要求还可以通过 requirements.toml 中的 [features] 表来约束功能标志。请注意，功能并不总是 security-sensitive，但企业可以根据需要固定值。省略的键仍然不受约束。

对于 Codex 0.138.0 或更高版本，首选具有 allowed_permission_profiles 和托管 default_permissions 的 权限配置文件 。仅将 allowed_sandbox_modes 用于仍配置 sandbox_mode 的旧部署。

有关确切的密钥列表，请参阅 配置参考中的 requirements.toml 部分 。

Codex checks requirement sources in this order. If the same setting appears more than once, the first value wins:

Codex checks these sources from top to bottom. For ordinary settings and lists, it uses the first value it finds. A later source can still provide a setting that earlier sources leave unset.

表格一次合并一个条目。对于 allowed_permission_profiles，后续来源可以添加早期来源未提及的配置文件名称。如果两个源设置相同的配置文件名称，则较早的源获胜。

为了向后兼容，Codex 还将旧版 managed_config.toml 字段 approval_policy 和 sandbox_mode 解释为要求（仅允许该单个值）。

当您在商业或企业套餐中使用 ChatGPT 登录时，Codex 还可以从 Codex 服务获取 admin-enforced 要求。这是 requirements.toml 兼容要求的另一个来源。这适用于 Codex 表面，包括 CLI、应用程序和 IDE 扩展。

转到 Codex managed-config 页面。

使用与 requirements.toml 相同的格式和密钥创建新的托管需求文件。

enforce_residency = "us" 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 entrypoints" }, ]

保存配置。保存后，更新的托管要求将立即应用于匹配的用户。有关更多示例，请参阅 示例 requirements.toml 。

管理员可以为不同的用户组配置不同的托管要求，还可以设置默认的回退要求策略。

如果用户匹配多个 group-specific 规则，则应用第一个匹配规则。 Codex 不会填充后续匹配组规则中未设置的字段。

例如，如果第一个匹配组规则仅设置 allowed_sandbox_modes = ["read-only"]，而后面的匹配组规则设置 allowed_approval_policies = ["on-request"]，则 Codex app 仅位于第一个匹配组规则中，不会填充后面规则中的 allowed_approval_policies。

当用户在商业或企业计划上启动 Codex 并使用 ChatGPT 登录时，Codex app 将在 best-effort 的基础上满足托管要求。 Codex 首先检查有效的、未过期的本地托管需求缓存条目，并在可用时使用它。如果缓存丢失、过期、损坏或与当前身份验证身份不匹配，Codex 会尝试从服务获取托管需求（重试），并在成功时写入新的签名缓存条目。如果没有可用的有效缓存条目并且获取失败或超时，Codex 将继续，而无需托管需求层。

缓存解析后，Codex 强制执行托管需求，作为上述正常需求分层的一部分。

此示例从不阻止 --ask-for-approval 和 --sandbox danger-full-access（包括 --yolo）：

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

要为托管用户禁用 Appshot，请设置 top-level allow_appshots 要求：

allow_appshots = false

Codex treats only allow_appshots = false as disabling Appshots. If the key is omitted, Appshots remain unconstrained by requirements and use normal product availability checks. App-server clients that read effective requirements through configRequirements/read receive the same restriction as allowAppshots; an omitted or null allowAppshots value doesn’t disable Appshots.

要禁用托管用户的 设备远程控制 ，请设置 top-level allow_remote_control 要求：

allow_remote_control = false

Codex treats only allow_remote_control = false as disabling device remote control. If the key is omitted, device remote control remains unconstrained by requirements and uses normal product availability checks. This requirement does not disable SSH remote connections.

使用 allowed_permission_profiles 控制用户可以选择哪些 built-in 和自定义 权限配置文件 。这是 permission-profile 等价的 allowed_sandbox_modes；使用与用户选择权限的方式相匹配的允许列表。

Permission-profile 白名单需要 Codex 0.138.0 或更高版本。 Codex 0.137.0 及更早版本忽略 allowed_permission_profiles 并托管 default_permissions。

仅在每个托管客户端运行支持版本后才使用下面的 permission-profile 示例。在队列升级完成之前，请勿部署托管自定义配置文件。

当该表出现时，它是允许的配置文件的完整列表。允许配置文件设置为 true。忽略或设置为 false 的配置文件将被拒绝，包括在未来 Codex 版本中添加的 built-ins。

此策略允许 read-only 和工作区访问，但不允许完全访问：

default_permissions = ":workspace" [allowed_permission_profiles] ":read-only" = true ":workspace" = true # ":danger-full-access" is omitted, so it is denied.

管理员可以在同一需求源中定义自定义配置文件。使用不会与用户加载的配置中的名称冲突的 organization-specific 配置文件名称。自定义名称不能以 : 开头，也不能使用保留的文件系统名称。

请勿将托管自定义配置文件部署到运行 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"

当用户应仅选择 admin-defined 配置文件时，请忽略所有 built-ins：

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"

即使用户无法直接选择 built-in :workspace 配置文件，自定义配置文件也可以扩展 :workspace。

权限允许列表按配置文件名称组合。由于 Codex 在系统要求之前检查云要求，因此云要求可以使用 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 时，Codex 默认为 :workspace。当 allowed_permission_profiles 不存在时，托管要求不会限制用户可以选择的配置文件名称。每个条目必须命名 built-in 配置文件或在加载的配置或需求源中定义的自定义配置文件。当应集中控制其行为时，在托管需求中定义自定义配置文件。

当一项托管策略应在不同主机上应用不同的沙箱要求时，请使用 [[remote_sandbox_config]]。例如，您可以为笔记本电脑保留更严格的默认设置，同时允许在匹配的开发盒或 CI 运行器上进行工作区写入。 Host-specific 条目当前仅覆盖 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"]

Codex compares each hostname_patterns entry against the best-effort resolved host name. It prefers the fully qualified domain name when available and falls back to the local host name. Matching is case-insensitive; * matches any sequence of characters, and ? matches one character.

在同一需求源中，第一个匹配的 [[remote_sandbox_config]] 条目获胜。如果没有条目匹配，Codex 保留 top-level allowed_sandbox_modes。主机名匹配仅用于策略选择；不要将其视为经过身份验证的设备证明。

您还可以限制网络搜索模式：

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

allowed_web_search_modes = [] 只允许“禁用”。例如，allowed_web_search_modes = [“cached”] 即使在 danger-full-access 会话中也会阻止实时 Web 搜索。

[experimental_network] 是实验性的，可能会发生变化。如果未在用户运行的 Codex 客户端版本和操作系统上验证这些要求，请勿在整个企业部署中广泛启用这些要求。 Windows 支持仍然有限；除非您已在您的环境中对其进行了测试，否则请避免将此策略应用于 Windows 用户。

当管理员应集中定义网络访问要求时，请在 requirements.toml 中使用 [experimental_network]。这些要求与用户功能是分开的。network_proxy 切换：他们可以在没有该功能标志的情况下配置沙箱网络，但当活动沙箱保持网络关闭时，他们不会授予命令网络访问权限。

experimental_network.enabled = true experimental_network.allowed_domains = [ "api.openai.com", "*.example.com", ] experimental_network.denied_domains = [ "blocked.example.com", "*.exfil.example.com", ]

仅当您还定义了 administrator-owned allowed_domains 并希望该许可列表具有排他性时，才使用 experimental_network.managed_allowed_domains_only = true。如果没有托管允许规则，则 user-added 域允许规则不会保持有效。

域语法、本地/私有目标规则、deny-over-allow 行为和 DNS 重新绑定限制与 代理审批和安全 中描述的沙箱网络行为相同。

您还可以为接收托管 requirements.toml 的用户固定功能标志：

[features] personality = true unified_exec = false # Disable specific Codex feature surfaces when needed. browser_use = false browser_use_full_cdp_access = false in_app_browser = false computer_use = false

使用 config.toml 的 [features] 表中的规范功能键。 Codex 标准化生成的功能集以满足这些引脚的要求，并拒绝对 config.toml 或配置文件功能设置进行冲突写入。

如果省略，则这些功能是策略允许的，但须遵守正常的客户端、平台和部署可用性。

要防止 Computer Use 在托管 Mac 锁定后运行，请添加以下要求：

[computer_use] allow_locked_computer_use = false

此要求不会启用 Computer Use。它仅防止在 macOS 上锁定使用。如果省略它，锁定使用仍然不受要求的限制，并且仍然受正常产品可用性和用户本地设置的影响。

使用 allowed_approvals_reviewers 要求或允许自动审核。将其设置为 ["auto_review"] 以要求自动审核，或在用户可以选择手动批准时包含“用户”。

设置 guardian_policy_config 以替换自动审核策略的 tenant-specific 部分。 Codex 仍然使用 built-in 审核者模板和输出合约。托管 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] 拒绝读取精确路径或全局模式。用户不能通过本地配置来削弱这些要求。

[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. ]

当存在 deny-read 要求时，Codex 会拒绝 full-access 权限，并将本地执行保留在 read-only 或工作区沙箱中，以便可以强制执行。在本机 Windows 上，托管 deny_read 适用于直接文件工具； shell 子进程读取不使用此沙箱规则。

管理员还可以直接在 requirements.toml 中定义托管生命周期挂钩。使用 [hooks] 作为挂钩配置本身，并将 managed_dir 指向 MDM 或 endpoint-management 工具安装引用脚本的目录。

要强制执行托管挂钩，即使对于本地禁用挂钩的用户，请将 [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"

笔记：

管理员还可以使用 [rules] 表从 requirements.toml 强制执行限制性命令规则。这些规则与常规 .rules 文件合并，并且限制性最强的决定仍然获胜。

与 .rules 不同，需求规则必须指定决策，并且该决策必须是“提示”或“禁止”（而不是“允许”）。

[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." }, ]

要限制 Codex 可以启用哪些 MCP 服务器，请添加 mcp_servers 批准列表。对于 stdio 服务器，匹配命令；对于可流式传输的 HTTP 服务器，匹配 url：

[mcp_servers.docs] identity = { command = "codex-mcp" } [mcp_servers.remote] identity = { url = "https://example.com/mcp" }

如果 mcp_servers 存在但为空，则 Codex 将禁用所有 MCP 服务器。

托管默认值合并在用户的本地 config.toml 之上，并优先于任何 CLI --config 覆盖，在 Codex 启动时设置起始值。用户仍然可以在会话期间更改这些设置； Codex 下次启动时重新应用托管默认值。

确保您的托管默认值满足您的要求； Codex 拒绝不允许的值。

Codex assembles the effective configuration in this order (top overrides bottom):

CLI --config key=value 覆盖适用于基础，但管理层覆盖它们。这意味着即使您提供本地标志，每次运行也会从托管默认值开始。

Cloud-managed 要求影响要求层（非托管默认值）。请参阅上面的 Admin-enforced 要求部分了解优先顺序。

如果文件丢失，Codex 会跳过管理层。

在 macOS 上，管理员可以在以下位置推送提供 Base64 编码的 TOML 有效负载的设备配置文件：

Codex parses these “managed preferences” payloads as TOML. For managed defaults (config_toml_base64), managed preferences have the highest precedence. For requirements (requirements_toml_base64), precedence follows the cloud-managed requirements order described above. The same requirements-side [features] table works in requirements_toml_base64; use canonical feature keys there as well.

Codex honors standard macOS MDM payloads, so you can distribute settings with tooling like Jamf Pro, Fleet, or Kandji. A lightweight deployment looks like:

避免在有效负载中嵌入机密或 high-churn 动态值。像更改控制下的任何其他 MDM 设置一样对待托管 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