Why Codex CLI Asks for Permission Every Time, and How to Tune the Sandbox and Approval Policy Without Going Full Access

You give Codex a task, walk away, and come back to find it has been sitting on a prompt for twenty minutes: "Codex wants to runnpm test, allow?" Approve it, and three steps later there is another one. If Codex CLI seems to ask for permission every time, that is not a bug and it is not random. It is the result of two settings, the sandbox and the approval policy, and once you understand what each one controls you can decide exactly how much Codex gets to do on its own.

This guide explains why the prompts appear, what the current permission modes mean, the config.toml keys and CLI flags behind them, the ways to cut the prompts down without removing the guard rails, and how to make sure you actually see the prompts that remain. It is based on the current Codex documentation; where a value has been retired we say so, because a lot of older blog posts still quote it.

Two settings, not one

Codex separates what it is physically able to touch from when it stops to ask. The sandbox answers the first question: which files it can write and whether it has network access. The approval policy answers the second: when an action falls outside what the sandbox allows, does Codex pause and ask you, hand the request to an automatic reviewer, or refuse? A prompt is what happens when an action crosses the sandbox boundary and the policy says "ask".

That framing explains the most common complaint. The default sandbox for a version-controlled folder is workspace-write: Codex can edit files inside your project but has no network access unless you enable it, and cannot write outside the workspace. So every npm install, every curl, every git push, and every write to a file outside the repo crosses the boundary and triggers an approval. Nothing is wrong; the sandbox is doing its job, and the policy is doing what you (implicitly) asked.

The sandbox modes

• read-only: Codex can read files and run commands inside a read-only sandbox. It may start here until you trust the working directory, either through the onboarding prompt or /permissions.
• workspace-write: the default for version-controlled folders. Writes are limited to the workspace and network access is off unless enabled.
• danger-full-access: no sandbox at all. The documentation marks it as not recommended, and the flag that turns it on has a name designed to make you think twice: --dangerously-bypass-approvals-and-sandbox (alias --yolo).

You set the mode with the --sandbox flag on the command line or sandbox_mode in ~/.codex/config.toml.

The approval policy

• on-request: commands the sandbox allows run without asking; actions beyond the sandbox can require approval. This is the setting behind the recommended Auto preset.
• never: Codex never prompts. It still works inside whatever sandbox mode you chose, so never plus read-only is a legitimate combination for CI. Pass it as --ask-for-approval never or -a never.
• untrusted: retired. If an old config, profile or script still contains approval_policy = "untrusted", remove it; the docs warn the client may fail to start.
• Granular: approval_policy = { granular = { ... } } keeps the categories you choose interactive and automatically rejects the rest. The categories are sandbox_approval, rules, mcp_elicitations, request_permissions and skill_approval.

The named modes in /permissions

In the CLI, /permissions opens a picker that wraps those settings into presets. The current documentation describes three plus a custom option:

• Ask for approval: always ask to edit external files and use the internet. Sandbox stays workspace-write. The docs recommend starting here.
• Approve for me: the same sandbox and an on-request policy, but eligible approval requests go to an automatic reviewer instead of to you (approvals_reviewer = "auto_review"; the default is "user"). Changing the reviewer does not widen the sandbox; it only changes who answers the question.
• Full access: unrestricted access to the internet and any file on your computer.
• Custom: whatever your config.toml says.

Which of these you see depends on the app version, the environment and any organisation-managed requirements, which can restrict the "Ask for approval" option. In the desktop app and IDE extension the same control sits below the composer.

What actually triggers a prompt

According to the approvals documentation, Codex pauses for: editing files outside the workspace; running commands that need network access; any action that leaves the sandbox or runs outside a trusted command set; app and MCP tool calls that advertise side effects; and destructive tool calls, when the tool annotates itself as destructive. If you are being asked constantly, one of those is firing constantly, and the fix is to address that category rather than to switch everything off.

Five ways to get fewer prompts without going full access

1. Use the Auto preset explicitly. codex --sandbox workspace-write --ask-for-approval on-request. Inside the workspace Codex stops asking; outside it still does.
2. Turn on network access for the workspace if package installs and API calls are what keep interrupting you:

   [sandbox_workspace_write]
   network_access = true

   The optional network_proxy feature can then constrain which domains that traffic may reach; it does not grant network access by itself.
3. Add execution-policy rules for commands you always trust, so npm test or make lint run without a question while anything unexpected still asks.
4. Route approvals to the automatic reviewer with approvals_reviewer = "auto_review" (the "Approve for me" mode) for sessions where you are not at the keyboard. If the option is missing or greyed out, the docs have a troubleshooting section for that.
5. Save the combination as a profile and start with codex --profile name, so a permissive setup for a scratch repo never leaks into your production checkout.

One more cause worth checking: a project marked trust_level = "untrusted" under [projects."/path/to/project"] requires approval for commands unless an execution-policy rule allows them, and also disables project-local configuration. If a single repository asks far more than the others, look there first.

When you should keep the prompts

The prompts are the product working. "Ask for approval" is the recommended starting point precisely because an agent that can reach the network and write anywhere is an agent you have to supervise in real time. Keep the prompts for repositories with secrets, for anything that deploys, and for the first week with a new codebase, when you do not yet know what the agent will try. Use never only where you have accepted the risk, such as a read-only CI job, and treat --yolo as what its name suggests.

Make sure you see the prompt when it comes

Fewer prompts means the ones left are the important ones, and the failure mode flips: instead of being interrupted too often, you miss the single interruption that mattered and the agent waits silently for an hour. Codex can play a sound or send a notification when it needs you; we covered the built-in options in the Codex CLI notifications guide and the terminal-bell approach in making Codex ding when a response is needed. If you run Codex alongside Claude Code, the comparison of their notification systems explains why the two behave differently when they stop.