Codex keeps asking for approval? Approval policies, sandbox and “don’t ask again” explained
Codex asks for approval when a command needs to leave its sandbox. Most “it keeps asking” complaints come from a sandbox that is too tight, a setting that no longer exists, or a “don’t ask again” that only lasted for the session.
SHORT ANSWER
In current Codex, approval_policy is on-request (the default: the model asks when it needs to), never, or a granular table; untrusted was removed and on-failure is now just another name for on-request. What decides how often you are asked is mostly the sandbox: with sandbox_mode = "workspace-write" Codex edits and runs commands inside your project without asking. For commands you always trust, add a prefix_rule with decision = "allow" in ~/.codex/rules/default.rules. That is also where “don’t ask again for commands that start with …” saves itself.
First: what changed in Codex
Many guides and forum answers describe settings that no longer work. Before tuning anything, check your ~/.codex/config.toml against this list:
| Old setting | Today |
|---|---|
approval_policy = "untrusted" | Removed. Codex reports “approval_policy = "untrusted" is no longer supported; remove this setting”. The docs suggest sandbox_mode = "read-only" with on-request instead. |
approval_policy = "on-failure" | Still accepted, but only as an alias for on-request. |
--full-auto | No longer in the CLI reference. The closest flag is --approve-for-me (alias --not-so-yolo): automatic approval review with on-request and the workspace-write sandbox. |
[profiles.name] inside config.toml | Since Codex 0.134.0, --profile name reads $CODEX_HOME/name.config.toml instead. A leftover profile = "x" key now raises an error. |
/approvals | Use /permissions (“Set what Codex can do without asking first.”) |
Codex’s documentation also moved: the old developers.openai.com/codex pages now redirect to learn.chatgpt.com.
How Codex decides to ask
Two settings work together. The sandbox limits what a command can touch: files outside the project, the network. The approval policy decides what happens when a command needs more than the sandbox allows.
| sandbox_mode | What Codex can do without asking |
|---|---|
read-only (default) | Read files and run commands in a read-only sandbox |
workspace-write | Read, edit and run commands in the working directory automatically |
danger-full-access | Everything, with no sandbox. Not recommended |
| approval_policy | Behavior |
|---|---|
on-request (default) | The model decides when to ask. Commands the sandbox allows run without approval |
never | Never asks. Anything that fails is returned to the model, not escalated to you |
{ granular = { … } } | Keep some prompt categories interactive and auto-reject the rest (sandbox_approval, rules, skill_approval, request_permissions, mcp_elicitations) |
So if you are in read-only, every edit needs a yes. That is the single most common cause of “Codex asks about everything”. Even in workspace-write, .git, .codex, .agents and .aws stay read-only, and network access is off unless you turn it on.
This is the sample configuration from OpenAI’s docs, with the workspace options explained:
Newer versions also offer permission profiles (default_permissions with built-ins :read-only, :workspace and :danger-full-access). Use either profiles or sandbox_mode, not both.
Presets in the CLI, the IDE extension and the app
You don’t have to edit TOML. In the CLI, /permissions opens the presets; in the app and the IDE extension there is a permissions control below the composer. The CLI presets are:
- Read Only: reads the workspace; approval is required to edit files or access the internet.
- Default: edits inside the workspace; approval is required to access the internet or edit other files.
- Full Access: edits outside the workspace and uses the internet without asking.
The app and the IDE extension describe the same choice as Ask for approval, Approve for me and Full access. Older IDE screenshots call them Chat, Agent and Agent (Full Access).
Allow specific commands with rules
When you want Codex to run one command outside the sandbox without asking (gh pr view, say), write a rule. Rules are experimental and live in a .rules file in a rules/ folder next to a config layer, for example ~/.codex/rules/default.rules:
allow: run outside the sandbox without prompting.prompt: ask before every matching command.forbidden: block without asking.
When several rules match, the most restrictive wins: forbidden beats prompt, which beats allow. Test a command with codex execpolicy check before you rely on a rule.
What “don’t ask again” actually saves
The approval prompt in the Codex CLI offers different kinds of “yes”, and they last for very different times:
| Option | How long it lasts |
|---|---|
| Yes, proceed | This one command |
Yes, and don’t ask again for commands that start with <prefix> | Permanently (written as a rule to ~/.codex/rules/default.rules) |
| Yes, and don’t ask again for this command in this session | Until the session ends |
| Yes, and don’t ask again for these files | File edits, for this session |
If you keep answering the session option, you will be asked again tomorrow. Pick the prefix option, or write the rule yourself.
Codex on Windows
Windows was where “it asks for everything” was worst. In issue #10187 an OpenAI team member explained why: “Without a sandboxing mechanism, all tool calls need to be manually approved on Windows.” Codex now has a native Windows sandbox and uses it by default:
mxc: the recommended sandbox on compatible Windows devices.elevated: the preferred fallback when MXC is unavailable.unelevated: a legacy fallback.
Run /setup-default-sandbox in the CLI to set up the elevated sandbox (or codex sandbox setup --elevated for IT). Windows 11 is recommended; Windows 10 1809 or newer is best-effort. If you work in WSL, Codex uses its Linux sandbox there, and WSL1 is no longer supported.
Project config only loads in trusted projects
A .codex/config.toml inside a repo is only read when you trust the project. If your project settings seem ignored, that is why. A trust entry in your user config looks like this:
Settings are layered, highest first: command-line flags and -c overrides, the trusted project’s .codex/config.toml, the --profile file, your ~/.codex/config.toml, then system defaults.
About --yolo
--dangerously-bypass-approvals-and-sandbox (alias --yolo) runs every command without approvals or sandboxing. The source code describes it as “EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed.” approval_policy = "never" with danger-full-access does the same thing from the config file. If you just want fewer prompts, workspace-write plus a few allow rules gets you there with the sandbox still on.
For the prompts you keep
Once Codex only asks about things that matter (the network, files outside the project, a push), the remaining problem is noticing the question. Pet Island puts Codex’s command and file-edit approvals on a small island at the top of your screen, with the command or the diff, so you can allow or deny them without finding the right terminal. It shows when Codex is working and done, and Codex questions take you to the right window in one click. It works with the Codex CLI and the Codex app, and if the island is closed, Codex asks in its own window as usual.
FAQ
How do I stop Codex from asking for approval all the time?
Use sandbox_mode = "workspace-write" so Codex can edit and run commands inside your project, keep approval_policy = "on-request", and add prefix_rule entries with decision = "allow" in ~/.codex/rules/default.rules for commands you always trust.
Is approval_policy = "untrusted" still supported?
No. Current Codex rejects it with “approval_policy = "untrusted" is no longer supported; remove this setting”. Use sandbox_mode = "read-only" with approval_policy = "on-request" instead.
What happened to --full-auto?
It is no longer in the Codex CLI reference. The closest option is --approve-for-me (alias --not-so-yolo), which uses automatic approval review with on-request and the workspace-write sandbox.
Why does “don’t ask again” not stick?
“Don’t ask again for this command in this session” only lasts for the session. Choose “don’t ask again for commands that start with …”, which saves a rule to ~/.codex/rules/default.rules.
Why does Codex ask more on Windows?
Without a sandbox, every tool call needs approval. Codex now uses a native Windows sandbox by default; run /setup-default-sandbox if it is not set up.
Why is my project .codex/config.toml ignored?
Codex loads project config only for trusted projects.
Sources
Every setting and behavior on this page was checked against these pages on October 26, 2026. Agents change fast; if something no longer matches, the official page wins.
- OpenAI: Codex agent approvals and security
- OpenAI: Codex permission modes
- OpenAI: Codex config basics
- OpenAI: Codex sample config
- OpenAI: Codex rules
- OpenAI: Codex Windows sandbox
- OpenAI: Codex CLI reference
- OpenAI: Codex slash commands
- openai/codex source code (approval prompt, config errors)
- Issue #10187: Codex repeatedly asks for command approval
- Issue #5131: Always have to approve file edits
- Issue #29406: Approval prompt persists despite don’t ask again