Sandboxing and approval policy answer different questions. The sandbox defines what a command can reach; approval policy decides how eligible actions outside that boundary are handled. The effective result depends on the active sandbox or permission configuration, workspace and writable roots, platform, client and current policy.
What is the Codex sandbox?
The sandbox is a technical constraint applied to local command execution. When Codex runs a command on your machine, the sandbox determines which filesystem paths that command can access and whether it can open network connections. This is distinct from the agent's reasoning and from any approval prompt you might see.
The sandbox operates at the operating-system level. It does not inspect the contents of files, evaluate whether a document is appropriate for AI use, or determine whether a command's output is safe. It enforces a boundary on what the command can reach.
If you are comparing how different AI tools receive file content, the distinction between a deliberate chat attachment and a coding-agent workspace is the starting point. You can compare chat attachments with coding-agent workspaces to see how the two routes differ in what they expose and what controls apply.
Sandbox versus permissions and approvals
Codex currently documents two alternative ways to configure the command boundary, plus a separate approval decision:
- Legacy sandbox mode defines command filesystem writes and networking at a high level through
read-only,workspace-writeordanger-full-access. - Beta permission profiles combine more explicit filesystem and command-network rules in a named profile. They are an alternative to the legacy sandbox settings, not an extra layer underneath them.
- Approval policy determines how an eligible action outside the active boundary is handled. It may be refused, denied or reviewed. A prompt is not guaranteed for every blocked action.
Automatic approval review changes who evaluates an eligible escalation request; it does not change the underlying sandbox boundary. A broader approval posture does not widen the sandbox. The official approvals and security documentation describes the layered relationship and recommends least-privilege operational guidance.
For the full configuration of permission profiles, filesystem rules and network scope, see configure Codex permissions and approvals.
What the sandbox constrains: files, commands and network access
The sandbox governs four surfaces for local commands:
Filesystem reads. Do not assume the legacy read-only or workspace-write names restrict reads to the workspace. In the documented legacy model, these modes primarily distinguish write and network restrictions, and commands may read more broadly wherever the operating system permits. A current permission profile can add explicit read scope and deny rules.
Filesystem writes. Write access is narrower than read access in most modes. A command that can read a file does not automatically have permission to modify it.
Command networking. Whether a spawned command can open a network connection is a separate boundary from the agent's web search, connectors, MCP servers, browser or computer-use activity, and cloud execution. Command networking is the network access available to the process the sandbox governs; it is not the same as the agent's own tool surfaces.
Spawned commands. When an allowed command spawns a child process, that child inherits the active sandbox boundary. The child does not receive a wider scope simply because it was launched by a permitted parent.
Current sandbox modes compared
The current legacy sandbox modes, as documented by OpenAI, are read-only, workspace-write and danger-full-access. These names describe the scope of filesystem and network access available to local commands. They are not security verdicts; they are configuration settings that define a boundary.
| Legacy mode | File access | Command networking | What to verify |
|---|---|---|---|
read-only | Writes blocked; reads may extend beyond the workspace | Disabled by default | Actual readable paths and whether approval policy permits an eligible escalation |
workspace-write | Writes limited to configured writable roots; reads may be broader | Disabled by default | Every writable root, read exposure and any deliberate network exception |
danger-full-access | No sandbox filesystem restriction; host permissions still apply | Permitted | Use only where wider access is necessary and the environment is separately isolated |
The workspace-write mode is the project-scoped editing concept. Its name describes where commands may write, not a guarantee that commands can read only the project. Verify the read exposure separately, and keep writable roots limited to what the task needs.
The danger-full-access mode is named here only to explain the consequence of removing the boundary. It is not a recommendation. If a task appears to require broader access, identify the specific additional root or network requirement and configure a bounded adjustment, or use a separately isolated test environment.
Why beta permission profiles are a separate configuration system
OpenAI's documentation describes a Beta permission-profile system that combines filesystem and network rules into named profiles. The current built-in profiles use colon-prefixed names: :read-only, :workspace and :danger-full-access. Custom profiles can express specific read, write, deny and network scope.
These profiles are an alternative configuration model to the legacy sandbox_mode settings. They do not normally compose with the older settings. Do not treat the profile names as renamed versions of the sandbox modes; they are a different system with different mechanics.
The permission-profile system is in active development. Its names, precedence rules, syntax and platform support may change. The official permissions documentation is the authoritative source for current profile mechanics and should be rechecked before making a configuration decision.
How workspace and writable roots affect file access
Workspace roots are central to where legacy workspace-write permits changes. They are not, by themselves, a complete description of every path a command can read.
Key distinctions:
- The current working directory is where a command starts and is normally writable in
workspace-write, but it is not necessarily the only readable path. - The repository root is a source-control concept; it does not define the sandbox boundary.
- Workspace and writable roots define where changes may be made in the legacy editing mode. There can be more than one, and deliberately configured writable roots may differ from the repository root.
- A permission profile can express read, write and deny scope more explicitly. Treat it as the active alternative configuration system rather than combining it with legacy-mode assumptions.
A Git worktree separates branches and checkouts for parallel work. It is not a security sandbox. A worktree gives you a separate checkout directory, but it does not impose filesystem or network containment on commands that run within it. For the narrow distinction between source-control isolation and a security boundary, see the Git worktrees documentation.
When evaluating a task, record read needs and write needs separately. Confirm that every write falls within the deliberate writable scope, then check whether the active system also imposes explicit read restrictions.
Platform and client differences to verify
Current documentation lists support for macOS, Linux, WSL2 and native Windows, with platform-specific enforcement mechanisms. The exact enforcement method, prerequisites and default behaviour can differ between platforms and client versions.
Before relying on a specific boundary, verify:
- which platform and client version you are using;
- whether the sandbox is active for your session;
- which workspace and writable roots are configured;
- whether any platform-specific prerequisites are met;
- whether the mode or profile you expect is actually the one in effect.
The official sandboxing documentation is the authoritative source for current platform behaviour and should be rechecked before making a configuration decision.
A before-you-run boundary check
Before starting a Codex task that involves file access or network use, work through this list:
- Identify the exact project and documents the task needs.
- Remove unrelated files from the working scope where practical.
- Check readable paths and writable roots separately; a path that is readable is not automatically writable or appropriate for the task.
- Check network requirements separately from filesystem requirements.
- Decide which boundary crossings should require approval and which should be refused outright.
- Run the first task on non-sensitive or recoverable material.
- Verify actual attempted reads, writes and network actions rather than assuming the prompt defines access.
Access control does not establish document trust. A file being reachable does not establish whether it has been checked for hidden instructions or prompt-injection risk. If you need to understand how instruction-like content in documents can affect AI behaviour, see understand prompt injection in documents.
Documents inside a coding-agent workspace
Before an outside specification, reference or client document enters a Codex workspace, check its content separately from the command boundary. .mdSiren checks supported document versions for prompt-injection and document-borne risks, returns Approved, Needs review or Quarantine, and keeps the current eligible Approved copy ready for retrieval into AI projects.
Revisions need their own checks. In a manual workflow, you would place the retrieved copy in the intended workspace; Codex's sandbox and permissions would continue to govern access and actions.
See the document checkpoint and its supported security scope, or Coming soon. Decisions are limited to the reported checks; Quarantine is a document-handling state, not operating-system quarantine. To place sandboxing in the wider workflow, see the agent harness guide.
What the sandbox does not guarantee
The sandbox is a boundary, not a guarantee. Specifically, it does not:
- inspect or approve the contents of a file;
- prevent prompt injection from a document that is already within the workspace;
- make every allowed action safe or appropriate;
- protect against a command that stays within the boundary but produces harmful output;
- replace human review of what the agent reads, writes or transmits;
- govern the agent's web search, connectors, MCP servers, browser activity or cloud execution.
A command running successfully within the sandbox does not establish that it is safe. The boundary limits reach; it does not evaluate intent or content.
Frequently asked questions
What is the Codex sandbox?
The Codex sandbox is the technical boundary applied to local command execution. It constrains which filesystem paths a command can read or write and whether it can open network connections. It is a separate control from approval policy, which determines what happens when a command attempts to cross the boundary. See the official sandboxing documentation for current mode names and platform details.
What files can Codex access?
It depends on the active configuration. The legacy read-only and workspace-write modes do not, by name alone, confine reads to workspace roots; commands may be able to read broadly wherever the operating system permits. read-only blocks writes, while workspace-write permits writes in the current workspace and other configured writable roots. Beta permission profiles can impose more explicit read, write and deny scope.
Can Codex write outside the workspace?
In read-only, writes are blocked. In workspace-write, writes outside the current workspace and configured writable roots are blocked. In danger-full-access, the boundary is substantially wider. Whether a blocked write can be reviewed depends on the active approval policy. Identify the specific output path and use the narrowest supported writable scope rather than widening the whole boundary.
Does the Codex sandbox block internet access?
The sandbox controls command networking separately from the agent's other network surfaces. In read-only and workspace-write modes, command networking is disabled by default. In danger-full-access mode, command networking is permitted. This is distinct from the agent's web search, connectors, MCP servers, browser or computer-use activity and cloud execution, which are governed by separate controls.
Is the sandbox the same as Codex permissions?
No. Legacy sandbox settings and Beta permission profiles are alternative ways to configure the local command boundary. Approval policy separately governs eligible review at that boundary. See the Codex permissions guide for profile mechanics.
Should I bypass the Codex sandbox?
Removing the boundary can broaden filesystem, command and network exposure. A generated command may then change more files or reach more services than the task requires. If a command is blocked or prompts repeatedly, diagnose the exact read, write or network need and apply the narrowest documented adjustment: an explicit profile rule, a bounded writable root or a separately isolated disposable environment. Do not remove the boundary to solve a configuration problem.
