OpenAI Codex Security Guide: Sandboxing, Approvals, Network and Admin Controls

OpenAI Codex can read a repository, run shell commands, edit files and reach the network, so its security depends almost entirely on how its sandbox, approval and network settings are configured and who is allowed to change them. Codex runs locally (CLI, IDE extension and desktop app) and as cloud tasks in OpenAI-hosted virtual machines, and each surface has different controls. This guide explains how identity, sign-in and workspace roles work, which settings an administrator can enforce, how to handle tokens and MCP servers, what Codex logs, and a hardening baseline. It is written for platform, AppSec and identity teams rolling Codex out to developers. For the general risks of coding agents, see the AI IDE and Coding Agent Security Guide; this page goes deeper on Codex itself. Settings were checked against OpenAI's Codex documentation on 27 October 2026 and change often, so confirm key names against the current configuration reference before enforcing them.

Key takeaways

• The sandbox and the approval policy are separate controls. Sandbox mode (read-only, workspace-write, danger-full-access) limits what commands can touch; the approval policy decides when Codex must stop and ask. Harden both.
• Enforce with requirements, not defaults. Values in config.toml are starting points a user can change. Limits set in requirements.toml, the Admin Console Agent Security page or MDM cannot be overridden.
• Network access is the main exfiltration path. Local network access is off by default and cloud internet access is a per-environment switch. Keep both off or on a domain allowlist, and use "Only allow domains added by admins".
• Credentials are the blast radius. Prefer cloud network secrets (the task sees a placeholder) over plain environment variables, store CLI credentials in the OS keyring, and never let an agent find a broad token in the repository.
• Analytics are not an audit trail. Use the Compliance API and opt-in OpenTelemetry events for evidence, and test that hooks fail safely before relying on them.

How identity and access work in Codex

Codex has two kinds of identity to manage: the human who signs in, and the credentials Codex itself uses while it works (repository access, API tokens, MCP server tokens and cloud secrets). Most incidents with coding agents involve the second kind.

Sign-in and authentication methods

• ChatGPT sign-in: users sign in with their ChatGPT account, which ties usage to a ChatGPT Business, Enterprise or Edu workspace and its single sign-on, SCIM and role settings.
• API key sign-in: Codex can also authenticate with an OpenAI API key, which bills to an API platform project and sits outside workspace governance.
• Forcing the method: forced_login_method (chatgpt or api) restricts Codex to one method, and forced_chatgpt_workspace_id limits ChatGPT logins to your workspace identifier. Together they stop developers using a personal account or an unmanaged API key on a corporate device.
• Cached credentials: cli_auth_credentials_store accepts file, keyring, auto or ephemeral. Prefer keyring (or ephemeral on shared build hosts) so a plaintext token is not left in the home directory.

Where each control lives

Admin roles and privileged access

The workspace roles are Owner (workspace-wide settings), Admin (supported operations and groups), Member (no administrative rights) and Analytics Viewer (workspace analytics). Owners can create custom roles in which each eligible permission is Default, On or Off. Role permissions combine additively: if any role a member holds sets a feature On, the member gets it even when another role sets it Off. Design custom roles so that the permissive role is the exception, granted through a small, reviewed group.

• Codex access toggles: "Allow members to use Codex locally" and "Use Codex in the cloud" are separate in most workspaces; enabling one does not enable the other. Turn on only the surface you have hardened.
• Manage workspace environments: this permission lets a member create and edit shared cloud environments, including their internet access and secrets. It is off by default. Treat it as privileged: grant it to a platform team group, not to all developers. Members with cloud access can still edit their own personal environments.
• Agent Security and the Policy API: whoever can edit Agent Security policy can loosen the sandbox, network and MCP limits for every user. Restrict this to Owners or a dedicated admin role, require phishing-resistant MFA through your identity provider, and review changes. See the Phishing-Resistant MFA Guide.
• Groups through SCIM: provision Codex access through SCIM-synced groups so leavers lose access when they leave the directory, rather than through direct member assignment.

Sandbox modes and approval policies

The flag --dangerously-bypass-approvals-and-sandbox (alias --yolo) removes both the sandbox and approvals, and OpenAI's own documentation advises against it. Block it in practice by setting allowed_sandbox_modes to ["read-only", "workspace-write"] or, on Codex 0.138.0 and later, by restricting allowed_permission_profiles. Older clients ignore the newer profile keys, so keep the legacy key until every device is upgraded.

The local sandbox is enforced by the operating system: Seatbelt (sandbox-exec) on macOS, bwrap with seccomp on Linux and WSL2, and MXC on Windows with legacy fallbacks. Inside writable roots, .git, .agents, .codex and .aws stay read-only, so the agent cannot rewrite its own configuration or Git hooks. Run codex sandbox with the platform subcommand to confirm the sandbox behaves as expected on your build images.

Integrations, API tokens and service accounts

Every credential Codex can reach is a credential a prompt injection can try to use. The question is not whether Codex is trustworthy, it is what a hijacked session could do with what it can see. ATT&CK describes the attacker side as T1552.001 Credentials In Files, and OWASP lists it under LLM06:2025 Excessive Agency.

• Cloud network secrets: in cloud environments, a network secret takes a key, a value and allowed domains. Programs receive a placeholder and the egress proxy substitutes the real value only for HTTPS on port 443 to those domains, so the raw credential does not land in a process or file. Use these for package registries and internal APIs instead of plain environment variables, which programs (and the agent) can read directly.
• Personal vault: shared environments can ask each user to supply their own secret from a personal vault, which keeps shared environments free of a team credential that everyone's tasks would use.
• Repository access: cloud environments check out the GitHub repositories selected when the environment is created. Limit environments to the repositories they need and review the GitHub app installation scope at the organisation level. GitLab and GitHub Enterprise Server are not supported for cloud environments, which rules cloud tasks out for repositories hosted there.
• MCP servers: an MCP HTTP server token should come from an environment variable named in mcp_servers.<id>.bearer_token_env_var, never written into the config file. Use enabled_tools and disabled_tools to expose only the tools needed, and keep stdio server env maps free of broad tokens. Admins can allowlist MCP servers by identity (command or URL) in requirements; an empty list disables all of them. See the MCP Security Guide.
• Tokens on developer machines: a local Codex session inherits whatever the developer's shell can reach: cloud CLI profiles, .npmrc tokens, SSH agents. Use [permissions.filesystem] deny_read in requirements to block reads of credential paths, keep the network off, and move long-lived tokens to short-lived federation. The PocketOS database deletion shows the failure: a coding agent (not Codex) found an account-scoped API token in an unrelated file and used it to delete a production volume.
• CI service accounts: when Codex runs non-interactively in a pipeline, give it a dedicated API key in a dedicated project, use read-only with never, and avoid granting the pipeline token write access to the repository unless the job must push.

For the identity model behind these controls, see the Agent Identity and Access Guide.

Logging and detection

Codex gives four sources of evidence, and they answer different questions.

Configure the [otel] block (exporter otlp-http or otlp-grpc, environment label) in user-level or managed configuration: project-local .codex/config.toml files ignore telemetry and notification keys, so a repository cannot redirect your telemetry. Leave log_user_prompt = false unless you have a lawful basis and a retention plan for prompt text.

Detections worth building:

• Tool decisions where the user approved a command that writes outside the workspace or opens network access.
• Sessions started with full access or the bypass flag on any managed device (a requirements fallback notice also tells the user it was blocked).
• Codex processes reading credential files or cloud CLI profiles, correlated with endpoint telemetry.
• Cloud environments whose internet access changed to All (unrestricted) or gained new allowed domains.
• Changes to Agent Security policy, custom roles or the "Manage workspace environments" grant.

Feed these into the same pipeline as your other NHI detections. See the Detection Engineering for Non-Human Identities Guide.

Hardening baseline

1. Decide surfaces first. Enable local Codex, cloud Codex or both per group. Start with a pilot group on local Codex with the defaults below.
2. Pin authentication. Set forced_login_method = "chatgpt" and forced_chatgpt_workspace_id through MDM or system requirements, and cli_auth_credentials_store = "keyring".
3. Enforce the sandbox. In requirements, allow only read-only and workspace-write (and the matching permission profiles on 0.138.0+), and block the never approval policy for interactive users.
4. Close the network. Keep local network access off; if a team needs it, use the network proxy with explicit domain rules (deny always wins) and enable "Only allow domains added by admins". Keep dangerously_allow_non_loopback_proxy and dangerously_allow_all_unix_sockets false. Set allowed_web_search_modes = ["cached"] so web results come from the pre-indexed cache rather than live pages.
5. Allowlist MCP servers and add command rules. List approved servers by identity; use prefix_rules with prompt or forbidden for destructive commands such as package publishing, git push --force or cloud deletion. Requirements cannot set a rule to allow, which is by design.
6. Harden cloud environments. Internet access off, or "Package managers" plus specific additional domains; network secrets instead of environment variables; only required repositories; shared environment editing limited to the platform group.
7. Mark untrusted projects. Use trust_level = "untrusted" for cloned third-party repositories, and review AGENTS.md and .codex/ files in pull requests like code. See Coding Agent Configuration File Attacks.
8. Turn on evidence. Connect the Compliance API to the SIEM and deploy the OTel collector endpoint before broad rollout.
9. Test, then widen. Confirm a blocked mode falls back with a notice, a denied domain fails, and a deny_read path cannot be read. Roll out in rings; to roll back, revert the policy version in Agent Security or the MDM profile, which clients reapply on next start.

Framework mapping

Common misconfigurations

• Relying on config.toml for policy. Defaults are editable. Without a requirements file, MDM profile or Agent Security policy, any developer (or any script running as that developer) can switch to full access.
• Bypass flags in scripts and aliases. Shell aliases and wrapper scripts that add --yolo spread quickly. In the Nx s1ngularity attack, malware ran installed AI coding CLIs with permission-bypass flags to search developer machines for secrets; requirements that block bypass modes turn that from a silent theft into a refused command.
• Unrestricted cloud internet. Setting a shared environment to All (unrestricted) to fix one failing install leaves every task in that environment able to send repository content anywhere. Add the specific domain instead.
• Secrets as environment variables. Plain variables are readable by every program in the task, including code the agent was tricked into running. Use network secrets with allowed domains.
• Deny-only domain lists. A deny-only managed network policy allows nothing else, which surprises teams and pushes them to turn management off entirely. Write allow rules for what is needed.
• Trusting hooks to block. A failing or slow PreToolUse hook may not block the tool. Test failure behaviour and keep sandbox and rules as the real enforcement.
• Additive roles granting too much. A broad custom role with environment management On overrides narrower roles. Review effective permissions, not role definitions alone.

Practitioner checklist

• Pin forced_login_method and forced_chatgpt_workspace_id on managed devices and store CLI credentials in the keyring.
• Enforce allowed sandbox modes or permission profiles so danger-full-access and the bypass flag are unavailable.
• Keep local network access off; use admin-managed domain allowlists and cached web search where access is needed.
• Harden every shared cloud environment: internet off or allowlisted, network secrets only, minimum repositories.
• Grant "Manage workspace environments" and Agent Security editing to a small, MFA-protected admin group.
• Allowlist MCP servers by identity, keep their tokens in environment variables and expose only required tools.
• Block reads of credential paths with deny_read and remove broad tokens from repositories.
• Stream Compliance API records and OTel events to the SIEM and alert on policy changes and full-access attempts.
• Test every enforced setting on each OS build before widening the rollout, and document the rollback.

Standards and references

• OpenAI: Codex Agent Approvals and Security
• OpenAI: Codex Managed Configuration
• OpenAI: Codex Agent Security
• OpenAI: Codex Cloud Environments
• OpenAI: Codex Governance
• OpenAI: Codex Configuration Reference
• OWASP: Top 10 for LLM Applications 2025
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: AI IDE and Coding Agent Security Guide · AI Coding Agents Security Guide · Gemini CLI and Gemini Code Assist Security Guide · MCP Security Guide