OpenAI's Codex pairs a sandbox mode, which limits what the agent can touch, with an approval policy, which decides when it must ask. The documented default is workspace-write with on-request approvals and network off. For folders outside version control, the documentation recommends read-only.
The settings, as documented
OpenAI's documentation on agent approvals and security describes three sandbox modes and several approval modes.
| Setting | What the page says |
|---|---|
| read-only | Sandbox mode with no edits |
| workspace-write | The default "Auto" preset. Codex can edit files and run commands in the working directory, and asks before editing outside the workspace |
| danger-full-access | No sandbox and no approvals, and the page does not recommend it |
| on-request approval | Commands allowed by the sandbox run without approval. Codex asks before leaving the sandbox or using network access, if enabled |
| never approval | Disables approval prompts, and works with every sandbox mode |
| granular policy | Keeps selected prompt categories interactive and automatically rejects the rest |
The page also states that the agent runs with network access turned off by default, and that inside workspace-write the network stays off unless a specific setting enables it. It notes that an older approval value is retired and can prevent startup, so remove it from configuration.
What the combinations mean in practice
The two settings multiply. Read them as a grid.
| Sandbox | Approval | Effect | Suitable for |
|---|---|---|---|
| read-only | on-request | Reads freely, cannot edit, asks if it needs more | Exploring unfamiliar code, folders not under version control |
| workspace-write | on-request | Edits and runs inside the workspace, asks to leave it | Day to day work on a feature branch |
| workspace-write | never | Edits and runs inside the workspace, never asks, still confined | Unattended tasks in a throwaway environment |
| danger-full-access | never | No limits at all | Not recommended by the documentation |
The third row is worth thinking about. Disabling prompts is not the same as removing limits, because the sandbox still bounds what happens. The dangerous cell is the last one, where both controls are gone.
Recommended practice from the documentation
The page recommends the Auto preset for version controlled folders and read-only for folders without version control. It suggests setting values explicitly, for example by passing both the sandbox and approval flags on the command line, so behavior does not depend on defaults that may change. It advises working on a feature branch with a clean git status and reviewing diffs before accepting changes, and it advises keeping prompt logging off unless policy permits storing prompts.
Turn those into a short team standard:
- Always set sandbox and approval explicitly in a shared configuration.
- Start in a feature branch with a clean status.
- Keep network off unless a task needs it, and enable it per task.
- Review every diff.
- Decide whether prompts may be stored, and write down the answer.
Cloud tasks
For cloud tasks, the documentation describes isolated, OpenAI managed containers, where setup can reach the network to install dependencies and the agent phase runs offline by default unless internet access is enabled for that environment. Secrets for cloud environments are available only during setup and removed before the agent phase starts. It also says local command line and editor use rely on operating system level sandboxing with settings you configure yourself. Check the current page for the latest cloud details, because it says current cloud behavior is documented elsewhere.
That secrets pattern is a good model for any team: give the agent credentials only while it needs them, and remove them before it starts working on untrusted text.
A worked example: choosing per repository tier
| Repository tier | Sandbox | Approval | Network |
|---|---|---|---|
| Public library | workspace-write | on-request | Off, mirror when needed |
| Internal service | workspace-write | on-request, granular for installs | Off by default, per task opt in |
| Restricted code | Not allowed until reviewed | Not applicable | Not applicable |
| Unversioned scratch folder | read-only | on-request | Off |
Checking what is really enforced
Test the settings on a throwaway project. Ask a read-only session to create a file. Ask a workspace-write session to edit a file outside the workspace and to fetch a page. In each case you should see a block or a prompt. Record the result with the tool version, since behavior changes over time.
Writing the team standard
Turn the grid into a one page standard that engineers can read in two minutes.
| Item | Standard |
|---|---|
| Default sandbox | workspace-write for version controlled projects, read-only elsewhere |
| Default approval | on-request |
| Network | Off by default, enabled per task with a note in the pull request |
| Full access mode | Not permitted |
| Prompt storage | Off unless policy permits |
| Explicit settings | Required in shared configuration |
| Review | Every diff read by the author and a second reviewer |
Add an exception path for unusual work, with an owner, a reason, and an expiry date. Then spot check a few developer machines each quarter, since local settings can differ from the standard.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice that checks apply to a change regardless of the sandbox settings of the session that wrote it.
Where Safeguard fits
Sandbox and approval settings govern the session. Safeguard works at the dependency and pipeline end: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is "never" approval the same as full access?
No. It disables prompts and works with every sandbox mode, so a confined sandbox still limits what happens. Full access is the separate mode with no sandbox.
Which setting is safest for a folder outside version control?
The documentation recommends read-only for such folders, since changes there cannot be reviewed as a diff.
Should we rely on defaults?
Set sandbox and approval values explicitly in shared configuration, so a default change does not alter your posture silently.
Sources
Last reviewed: 19 October 2026.
