The short version: OpenAI Codex is no longer a passive code-completion tool – it’s a coworker with tools. It runs long-running tasks, connects to browsers, reads and writes files, executes shell commands, installs dependencies, calls MCP servers, and drives automations across local app, CLI, IDE, cloud, GitHub, Slack, Linear, mobile, and SSH. An agent that can execute code, reach the network, and act inside signed-in browser sessions is a far larger attack surface than a chatbot in a text box.
What this guide covers: how to set Codex up correctly — the configuration that gets you the most capability with the least exposure. Which defaults to keep, which to change, which settings to lock so users can’t weaken them, and how to roll it out without getting ahead of your controls.
“Workspace” means two different things. A ChatGPT workspace is the enterprise admin container – members, roles, Codex enablement, analytics, compliance. A local Codex workspace is the project folder Codex is operating in. When you see workspace-write, it refers only to the local sandbox boundary – not the admin container. Confusing the two leads straight to misconfiguration.
RBAC is split across two control planes. ChatGPT workspace roles govern Codex workspace features; OpenAI Platform roles govern API projects, service accounts, and Agent Builder workflows. Separate roles, separate identifiers, separate audit paths. Review both.
Security lives in config files, not one admin panel. The most important enforceable control is a cloud-managed requirements.toml policy. Defaults set starting behavior; requirements.toml sets admin-enforced limits users cannot weaken. Treat these policies like infrastructure-as-code – version-controlled, reviewed, and governed like any production change.
Prompt injection connects every risk. Web pages, documents, AGENTS.md, MCP responses, and plugin output can all carry hidden instructions. Because Codex can act, a successful injection has real blast radius. Keeping command network access off by default is one of the highest-leverage mitigations you have.
Before the recommendations, here’s what each control actually does. These four runtime settings are the ones you’ll tune most – listed from safest to riskiest value.
| Setting | What it controls | Values (safe → risky) |
|---|---|---|
sandbox_mode |
Where Codex can write files and run commands. | read-only (no writing or execution) → workspace-write (edit/run only inside the workspace, read everywhere) → danger-full-access (read/write/run anywhere – avoid unless the environment is already isolated) |
approval_policy |
How often Codex pauses to ask before it acts. | untrusted (prompts most often) → on-request (balanced default) → never (no prompts; automation only) |
web_search |
Whether the built-in search tool can run. | disabled → cached (an OpenAI-maintained index, not live pages) → live (the live internet – avoid without a reason) |
[sandbox_workspace_write]network_access |
Whether shell commands (e.g. curl) can reach the network. You must set this and web_search, or the agent can route around one via the other. |
false → true |
And the terms that describe where those settings live and how the model is instructed:
config.toml – sets Codex’s starting behavior. Personal defaults live in ~/.codex/config.toml; per-project overrides live in <project>/.codex/config.toml. Users can edit their own.requirements.toml – admin-enforced limits, deployed as a cloud-managed policy, that cap what users can choose (allowed_sandbox_modes, allowed_approval_policies, allowed_web_search_modes, and feature pins like browser_use). Users cannot weaken these. This is the difference between a suggested default and an enforced one.workspace-write refers only to the second one.AGENTS.md – always-on, natural-language instructions Codex reads throughout a session (repository or account level). Useful for shaping behavior, but it’s guidance, not an enforced boundary.SKILLS.md / skills – specialized instructions that load only when a particular task needs them, keeping context focused. Review them like software.
Enforceable controls are the runtime settings Codex actually applies: sandbox_mode, approval_policy, web_search, network access, and the admin-enforced requirements.toml limits. These are the boundaries you can rely on.
Natural-language guidance is everything expressed as instructions to the model: prompts, AGENTS.md, SKILLS.md, subagent definitions. These shape behavior and are useful, but they are not security boundaries – the same untrusted-input problem behind prompt injection means a model can be talked out of a natural-language rule.
Worth internalizing: filesystem controls can’t fully prevent Codex from reading files it’s pointed at. Assume anything reachable in the workspace is readable by the agent, and by extension by any injection that hijacks it. Put your real trust in config and enforced policy; use prompts and AGENTS.md to raise the bar, never as your only line of defense.
Codex’s defaults are more sensible than a wide-open agent platform, but they still leave real decisions to the user unless an admin enforces limits.
workspace-write + approval_policy = "on-request" for version-controlled folders, read-only for others. Reasonable – but users can still choose broader modes unless you enforce requirements.toml.cached (an OpenAI-maintained index, not live pages).workspace-write.The two configurations to keep away from normal users are danger-full-access and approval_policy = "never". Both belong to break-glass or tightly contained non-interactive jobs – not a managed laptop with access to corporate data. The core gap is the one every agent platform shares: defaults protect the starting state, but nothing stops a user from widening their own sandbox unless you enforce a policy they can’t override.
requirements.tomlThis is the single most important local-runtime control. Codex Admins deploy cloud-managed requirements.toml policies that apply to ChatGPT-signed-in local surfaces (app, CLI, IDE) and set limits users can’t weaken. For most users:
allowed_sandbox_modes to ["read-only", "workspace-write"].allowed_approval_policies to ["on-request", "granular"].allowed_web_search_modes to ["disabled", "cached"].browser_use, in_app_browser, and computer_use to false for stricter groups.Then create a baseline policy for most users, configure a default fallback policy so users outside explicit groups still land somewhere safe, and order group rules carefully – if a user matches more than one, the first match applies, and Codex does not fill missing fields from later rules. Use the policy lookup tool to confirm what a real pilot user actually receives before rollout.
Restrict behavior globally in ~/.codex/config.toml, then loosen per-project only where justified:
# ~/.codex/config.toml approval_policy = "on-request" sandbox_mode = "workspace-write" # edit/run only in workspace; read elsewhere web_search = "disabled" # or "cached" [sandbox_workspace_write] network_access = false # no outbound network from shell commands
You have to configure network access in two places or the agent will route around you: web_search controls the search tool, and [sandbox_workspace_write].network_access controls whether shell commands (like curl) can reach the network. Allow only disabled/cached search for managed users; if live network access is genuinely needed, use an administrator-owned domain allowlist, never a broad * rule. Add deny-read rules for secrets and credential stores, and filter environment variables so credentials aren’t exposed to the agent.
A project that truly needs the network loosens only what it needs:
# <myproject>/.codex/config.toml web_search = "cached" [sandbox_workspace_write] network_access = true
Use the least powerful surface that solves the task – a localhost preview doesn’t need the user’s signed-in Chrome profile. Disable Browser Use, Chrome, and Computer Use for lockdown groups via managed feature pins. Keep “Always allow browser content” off, and require explicit approval for admin consoles, customer systems, payment flows, and HR/legal/finance tools. Remember that granting Computer Use its Screen Recording and Accessibility permissions makes screen contents, open files, and clipboard state model-visible – keep it off for sensitive groups. Treat Atlas and Agent Mode as disabled or limited to a low-risk pilot; Atlas has known audit and compliance gaps.
The local sandbox doesn’t protect hosted containers, GitHub App installations, or Slack/Linear-created tasks. Scope the GitHub Connector to approved repos, keep branch protection on, review setup scripts, and keep agent internet access off unless a narrow allowlist is justified. On the Platform side, keep personal API keys out of CI and automation – use project-scoped service accounts separated by data class, rotate keys, and remove unused ones. Note that Compliance API exports do not cover API-key automation the way they cover ChatGPT-authenticated flows. For agents, agent-owned connections are the highest-risk setting – prefer end-user authentication or a reviewed service account over a builder’s personal credentials.
Apps, MCP servers, plugins, skills, hooks, and .codex/ content are supply-chain inputs whose output may carry hidden instructions. Start with a narrow allowlist, scope OAuth credentials, require approval for tools that can cause side effects, and review changes to skills, hooks, AGENTS.md, and .codex/ like code—with named owners and review dates.
Use the Plutonium Marketplace to discover safely vetted ecosystem components.
Codex spreads its audit signal across three separate streams:
codex exec, CI runs) the way it covers signed-in flows – those need runner logs and API-org records instead – and platform retention is time-boxed, so export to your own SIEM/DLP/eDiscovery if you need records to live longer.[otel] in requirements.toml (not project-local config, so a user can’t quietly turn it off). Set log_user_prompt = false unless policy explicitly allows prompt-content collection – prompts routinely contain source code, credentials, and customer data. The events worth alerting on: policy-load failures, sandbox escalations, denied file reads, and approval outcomes – especially a denial that’s immediately retried.Hooks for advanced enforcement. Logging tells you what happened; hooks let you intervene while it’s happening. Codex supports hooks – custom scripts that fire on lifecycle events, such as before a command runs or a tool is invoked. When the built-in settings don’t express the policy you need, a hook can inspect, block, redact, or log an action programmatically, giving you a genuine enforcement point rather than a natural-language request the model might ignore.
Prompt injection is the thread running through every surface above. Malicious instructions hide in web pages, documents, AGENTS.md, MCP responses, plugin output, setup scripts, and untrusted PRs. Because Codex can act, a successful injection isn’t just a bad answer – it can attempt to run commands, reach the network, or operate a signed-in browser.
The good news is that the controls you’d configure anyway are also your injection defenses: command network access off by default removes the easiest exfiltration path, deny-read on secrets limits what an injection can steal, on-request approvals put a human in front of high-impact actions, and allowlisted tools shrink what an injection can abuse. Treat all model-visible content as untrusted data, not operator instructions – and build your controls around limiting what a successful injection can accomplish, because natural-language defenses alone won’t stop it.
Don’t make the first rollout a feature tour. Start with the surfaces users actually need, prove the policy applies to real users, connect the audit trail, then widen by group.
workspace-write + on-request; no Full Access; Browser Use, Chrome, and Computer Use disabled. Configure managed requirements and a fallback policy, and wire Analytics, Compliance API, and OTel before expanding. Verify a real pilot user gets the expected policy.workspace-write or read-only; Full Access and approval_policy = "never" blocked or exception-based.disabled/cached; shell network off unless an admin allowlist is defined.AGENTS.md/.codex/ reviewed like code.Codex ships with more reasonable defaults than a wide-open agent platform – workspace-write sandboxing, on-request approvals, cached web search, and command network access off by default are all sensible starting points. The real work is in what those defaults don’t do on their own: enforce limits users can’t weaken, govern each surface separately, wire up a fragmented audit trail, and contain background and browser-connected work.
The building blocks are all there. A safe deployment is mostly a matter of assembling them deliberately: enforce your baseline with requirements.toml, keep the network and secrets locked down, treat the tool supply chain and both RBAC planes as first-class governance objects, and prove your policies apply to real users before you widen access. Prompt injection remains unsolved, so the goal isn’t to eliminate it – it’s to keep the blast radius small when it happens.
This is exactly the kind of risk we tackle at Pluto – the first workspace security platform built for the AI era, letting every employee, from engineering to marketing, build with AI securely. Want to learn more? Get in touch.
