Rolling Out OpenAI Codex Across Your Fleet: A Governance Guide (2026)

OpenAI Codex governance is the decision you make before the rollout email goes out, not after the first incident review. Codex runs across the CLI, an IDE extension, a desktop app, the cloud, and GitHub - and each surface inherits its own defaults - so "we approved Codex" is not a policy, it is the start of one. The concrete tension: a developer on a license-text repo and a developer on a monorepo full of deploy scripts can both be running workspace-write, and nothing in the tool tells you which is which.

This guide walks the controlled rollout end to end: the baseline approval and sandbox floor, repo trust tiers, secret handling, network egress, MCP and skill drift, and what your audit story actually is once Codex is everywhere. Every tool-behavior claim here is grounded in OpenAI's published Codex security and approvals documentation. If you are doing this for the broader category and not just Codex, pair it with securing AI coding agents and CLIs.

We will be specific about where OpenAI's own controls stop and where you still own the gap. Codex gives you strong per-process boundaries and an enterprise enforcement file; it does not give you a fleet inventory or a queryable record of what each agent did. That second layer is where Anomity's runtime governance comes in - but earn that later in the post. First, the dials.

How do Codex's two security dials actually work?

Per OpenAI's documentation, Codex separates two controls that engineers routinely conflate. The sandbox decides what the agent can technically do to the filesystem and network. The approval policy decides when Codex must stop and ask. They are orthogonal - you pair them - so the combination matters more than either value alone. We covered the mechanics in depth in Codex's sandbox and approval model; here we use them as rollout primitives.

Sandbox modes are read-only (inspect files, no edits or commands without approval), workspace-write (read, edit inside the workspace, run routine local commands), and danger-full-access (no filesystem or network boundary). Approval policies are untrusted (only known-safe read operations run automatically), on-request (work inside the sandbox, ask to go beyond it), and never (no prompts). The docs note that danger-full-access paired with never is the combination surfaced under a --yolo-style alias and explicitly marked not recommended.

The rollout move is to pick the baseline row, set it as an enforced floor, and make every step away from it a deliberate, visible decision rather than a per-developer default.

How do you set a baseline approval and sandbox policy?

For most teams the baseline is workspace-write + on-request. It gives developers a productive loop while keeping out-of-workspace writes and network behind an explicit ask. A developer's local config.toml expresses it like this, but the same keys are what you will later pin as an enforced floor:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false
# .git, .codex and .agents stay read-only inside writable roots

Two details from the docs matter for the rollout. First, inside a writable root Codex keeps .git, .codex, and .agents directories read-only, so the agent cannot quietly rewrite its own config or your history. Second, OpenAI also offers a granular approval object and an approvals_reviewer = "auto_review" mode that auto-evaluates sandbox escalations, blocked network requests, and destructive MCP calls. Decide centrally whether auto-review is part of your floor. The decision matrix below maps repo sensitivity to the floor you enforce, which ties directly into the fleet inventory you will need to confirm it is actually applied.

How should you tier repositories by trust?

A single Codex profile across every repo is the most common rollout mistake. The blast radius of workspace-write on a repo of static assets is nothing like the same setting on a monorepo whose scripts touch production. Codex's own behavior reinforces tiering: per the docs, in a version-controlled folder the default approval posture is on-request, while a non-version-controlled folder defaults to read-only - OpenAI already treats provenance as a trust signal.

• Tier 1 - open: public, docs, sample repos. read-only + untrusted, network off. The agent helps without ever needing to mutate state.
• Tier 2 - standard: the bulk of application code. workspace-write + on-request, network off by default with an explicit path to enable per task.
• Tier 3 - sensitive: infra, deploy scripts, anything secrets-adjacent or regulated. Tightest floor, deny-read globs on credential paths, network allowlist only, auto-review on.

Tiers are only real if you can confirm which tier a given machine is actually enforcing - which is an inventory problem, not a config problem. Command-injection paths like the one in the Codex branch-name GitHub token theft writeup are exactly why a deploy-script repo belongs in Tier 3 and never in Tier 1.

How do you handle secrets and network egress?

Codex does not strip your secrets for you. The sandbox limits filesystem and network reach, but credentials usually enter an agent through environment variables and dotfiles inside the workspace it is already allowed to read. OpenAI's managed configuration lets you set deny_read glob patterns under filesystem permissions to keep credential paths out of reach - use it for .env, cloud credential files, and private keys. The companion control is network: per the docs, network is off by default under workspace-write, and you turn it on explicitly.

[sandbox_workspace_write]
network_access = true

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "internal.example" = "deny" }

[permissions.filesystem]
deny_read = ["**/.env", "**/.aws/credentials", "**/*.pem"]

An allowlist-first proxy means open egress is a choice you have to make, not a default you inherit. Even with deny-read and a proxy, you still want a record of when an agent touched a credential path - that is where on-endpoint redaction and metadata-only audit earn their place. The multi-agent credential-theft pattern in comment-and-control prompt injection shows why a single trusted agent reaching the network is enough to matter.

How do enterprise admins enforce a floor?

OpenAI's managed configuration is the enforcement mechanism. requirements.toml is an admin-enforced file that constrains security-sensitive settings - allowed_approval_policies, allowed_sandbox_modes, allowed_permission_profiles, allowed_web_search_modes, managed hooks, and optionally which MCP servers users may enable. Per the docs it reaches devices three ways, in precedence order:

1. Cloud-managed requirements fetched from the Codex service - highest priority for ChatGPT Business and Enterprise workspaces, deployable from the Codex Policies page per user group.
2. macOS MDM via the com.openai.codex domain, using requirements_toml_base64 and config_toml_base64 keys.
3. System files at /etc/codex/requirements.toml on Unix or the %ProgramData%\OpenAI\Codex\requirements.toml path on Windows.

OpenAI also recommends scoping a dedicated Codex Admin group rather than handing administration to a broad audience, and backing it with your identity provider through SCIM so membership changes stay auditable. Requirements enforce values users cannot override; managed defaults set starting values they can. This is a genuine floor - but it is a floor on configuration, not a window into behavior. Compare how the three major CLIs differ in Claude Code vs Codex vs Cursor permission models before you assume one policy shape ports across all of them.

What about MCP servers, skills, and config drift?

Codex loads MCP servers, custom skills, plugins, and hooks, and each is its own trust decision. Managed configuration lets admins allowlist MCP servers by matching on the launch command for stdio servers or the url for HTTP servers, and constrain managed hooks through a managed_dir. The failure mode is drift: a developer adds an MCP server or skill that was never reviewed, the allowlist permits a broad pattern, and nothing surfaces the new artifact centrally.

• Inventory artifacts, not just config: treat MCP servers, skills, plugins, and hooks as first-class items you can enumerate per endpoint.
• Reconcile loaded vs allowed: compare what is actually running against what your requirements.toml permits - gaps are the early signal.
• Watch web search mode: allowed_web_search_modes can pin cached, live, or disabled; live web fetch is its own egress surface worth a policy.

Drift is a continuous problem, so the control has to be continuous too - a one-time config push will not catch the MCP server added next Tuesday. See how the rollout fits the overall flow for where reconciliation lives.

What is your audit story once Codex is everywhere?

OpenAI provides OpenTelemetry export, off by default, that can emit conversation starts, API requests, tool decisions, and tool results when you enable it under an [otel] block. That is useful telemetry, but it is opt-in per machine and gives you streams, not a governed, queryable fleet record. The honest summary: requirements.toml tells you what was allowed, OTel tells you what a machine chose to emit, and neither guarantees a single, central, queryable answer to "which Codex agents ran what, where, over the last quarter?"

If your compliance posture needs that answer on demand, the framework in our AI security framework report and the agentic AI governance guide walk through what a defensible audit trail looks like for agentic tools - beyond per-machine telemetry.

How Anomity governs OpenAI Codex

Anomity is the agentic endpoint layer that sits under the rollout you just designed. On every managed endpoint it inventories eight artifact types - AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs - and classifies them, so the drift question above becomes a query instead of a hope. That is the fleet inventory that confirms which trust tier each machine is actually enforcing and which MCP servers and skills are loaded against your allowlist.

On agents that expose a hook - including Codex's PreToolUse-style hook surface - Anomity returns allow / deny / log on each tool call before it runs. That is runtime governance at the hook: the deploy-script command in a Tier 3 repo can be denied, the credential-path read can be logged, and the routine edit can pass, all without the developer noticing friction on the safe path. It complements requirements.toml - the floor stays OpenAI's, the per-call decision and record are yours.

Every decision lands in a queryable 90-day audit trail, and Anomity collects metadata only with on-endpoint secret redaction, so "which agents touched a credential path last quarter?" is a query, not a forensic project. Decisions also route to SIEM, Slack, email, or Jira, and Anomity is SOC 2 Type II. It complements your Network, EDR, DLP, and GRC stack rather than replacing it. Compare the approach side by side on the comparison view.

A controlled Codex rollout is two halves: OpenAI's configuration floor, and a runtime-and-inventory layer that proves the floor holds and records what happened on top of it. If you are standing up that second half, request early access and bring your trust-tier matrix - we will map it to allow/deny/log policy on day one.