Codex CLI approval modes for real tasks
Codex CLI approval modes explained: map Suggest, Auto Edit and Full Auto to current sandbox and approval settings safely.
Faisal Karkoh · 11 Oct 2026 · 9 min read
Codex CLI approval modes are easiest to choose when you stop treating them as personalities and start treating them as permissions. For each task, use the least-permissive setup that lets Codex make progress, then widen access only when the repository state, task scope and tests justify it.
Evidence note: this article was verified against OpenAI Codex CLI, sandboxing, developer command and OpenAI Help Center documentation on 2026-10-11. It is not a hands-on benchmark. Older mode names and flags are version-dependent, and the latest observed openai/codex GitHub release at verification time was 0.162.1.
The short answer: old mode names are labels, not current universal flags
Many developers still search for Suggest, Auto Edit and Full Auto because older Codex CLI material used those names. Current OpenAI documentation separates the decision into two controls: approval policy and sandbox mode. OpenAI’s sandboxing documentation says approvals decide when Codex pauses before an action, while the sandbox decides which files and network resources commands can access.
That means the old labels can help with decision-making, but they should not be treated as guaranteed current command syntax. A 2025 issue in the OpenAI Codex GitHub repository describes the older TypeScript CLI as exposing options such as --suggest, --auto-edit and --full-auto, then explains that those options conflated approvals and sandboxing concepts later separated in the Rust CLI. Another OpenAI Codex GitHub issue shows older --approval-mode help output and an OpenAI member later noting that the latest version did not support that option.
| Old reader label | Current practical meaning | Use it when |
|---|
| Suggest-like | read-only sandbox with on-request approvals | You want Codex to inspect, explain and plan before it edits. |
| Auto Edit-like | workspace-write sandbox with on-request approvals | You want Codex to edit files inside the project but still pause when it crosses the boundary. |
| Full Auto-like | Ambiguous: it could mean workspace-confined automation, or true full access | Use exact current settings instead of the label, because the risk changes materially. |
| True full access | danger-full-access with never | Use only in a deliberately isolated situation where no prompts and no sandbox boundary are intentional. |
The practical rule is simple: use read-only with on-request for exploration, workspace-write with on-request for clean local edits, and true full access only when isolation is deliberate.
How current Codex permissions work
OpenAI’s Codex CLI documentation describes Codex CLI as the terminal surface for inspecting code, making changes, running commands and automating repeatable work from a local project directory. Current setup guidance is minimal: install Codex, open a project directory, run codex, then sign in.
OpenAI’s sandboxing docs separate the two controls the article explains: what the sandbox allows and when Codex pauses for approval.
Sandbox mode is the blast-radius control. OpenAI documents read-only, where Codex can inspect files but cannot edit files or run commands without approval; workspace-write, where Codex can read files, edit inside the workspace and run routine local commands inside that boundary; and danger-full-access, where Codex runs without sandbox restrictions. If a task only needs repository understanding, editing permission is unnecessary. If a task needs one writable directory outside the repository, prefer adding that specific directory rather than removing the whole boundary.
Approval policy controls when Codex pauses. OpenAI documents common policies including on-request, where Codex works inside the sandbox by default and asks when it needs to go beyond that boundary, and never, where Codex does not stop for approval prompts. These settings are independent. Full access is not merely “fewer prompts”: OpenAI defines full access as sandbox_mode = "danger-full-access" together with approval_policy = "never". By contrast, the lower-risk local automation preset is workspace-write with on-request.
Check the repo before you increase autonomy
Before widening Codex from inspection to edits, check the repository state. If the working tree is already dirty, it becomes harder to separate Codex’s changes from existing work. Run git status, or ask Codex to inspect the repo state before it edits. If the tree is dirty and the diff is not understood, stay restrictive until it is committed, stashed, isolated or reviewed.
For risky local work, create a branch or worktree before increasing autonomy. If you are preparing an existing production repository for repeat Codex work, start with a bounded setup such as the Codex repository setup workflow before relying on CLI permissions alone. If the task needs access outside the repository, use a specific additional writable directory where possible. The current OpenAI developer commands documentation lists --add-dir for granting extra writable directories.
This pre-flight step matters more than the old mode name. A clean repository with a narrow failing test is a good candidate for workspace-confined edits. A dirty repository with unknown changes is not.
Choose the setup by task type and test coverage
The right Codex CLI permission setup is the one that matches the task’s blast radius and the available checks. Do not use Full Auto language when you only mean “edit files without asking every time”. Describe the current sandbox and approval combination instead.
| Task | Least-permissive useful setup | Why |
|---|
| Repository explanation, architecture inspection or planning | read-only with on-request | The useful output is understanding. File edits add risk without helping the task. |
| Mechanical rename, copy update, small documentation change | workspace-write with on-request, if the tree is clean | The change is local, reviewable and reversible through git. |
| Lint fix or narrow failing test | workspace-write with on-request | Codex can edit workspace files while still asking before it crosses the boundary. |
| Dependency update or lockfile change | Supervised workspace-write, approve commands explicitly | Package manager commands and generated files can create wider side effects. |
| Auth, payments, secrets or production config | read-only first, then tightly supervised edits | Tests often do not fully represent the external system or security impact. |
| Database migrations or deployment scripts | Restrictive mode with explicit approval and diff review | The failure mode can affect data or production infrastructure, not only local files. |
| Deliberately isolated throwaway environment | danger-full-access with never, only if intended | This removes both prompts and sandbox boundaries, so isolation must be the safety layer. |
Then adjust for test relevance. No tests or unknown tests support diagnosis and small reviewed edits, not confidence that changed behaviour works. Lint and format checks support style and syntax cleanup, not business logic. Unit tests around the changed code are stronger for narrow workspace edits, while integration or end-to-end tests can support longer local validation for a narrow change. Gaps around databases, external services, secrets, permissions or live infrastructure should keep the work supervised even if local tests pass. For cases where the task itself is a poor fit for agentic edits, use the boundaries in when not to use Codex before deciding whether any approval mode is appropriate.
A worked example: fix a failing dashboard test without over-granting access
This example is illustrative, not an observed test result. Assume a TypeScript web app in a Git repository has one failing dashboard test. The working tree starts clean, and local validation commands are available: lint, the affected test file and a broader test suite.
Step 1: start restrictive for diagnosis
Start with a Suggest-like setup: read-only plus on-request. Paste the failing test name or command output into Codex and ask for inspection before editing:
Inspect the failing dashboard test. Explain the likely cause and propose a narrow plan. Do not edit files yet.
The expected output is a short explanation of the likely failure path and the files Codex thinks are relevant. If Codex proposes a broad refactor before proving the local cause, stop and narrow the prompt. The same principle applies to richer repo prompts: Codex prompt contracts for production development should constrain scope, files, validation and stop conditions rather than simply asking the agent to “fix it”.
Step 2: allow workspace-confined edits only if the plan is narrow
If the plan is limited to the dashboard component or a nearby test, and git status is still clean, move to workspace-write with on-request. Keep the request specific:
Apply the smallest fix for this dashboard test. Change only the dashboard component or its nearby test if justified. Explain every changed file.
At this point, allow file edits inside the workspace. Do not approve unrelated changes, generated files, environment files, migrations or deployment configuration for a dashboard test unless Codex gives a task-specific reason and you explicitly accept it.
Step 3: approve only understandable local commands
Approve commands such as the single failing test or lint command when the command is understandable, local and relevant. Question package manager commands unless the failure is actually dependency-related. Reject global installs, broad shell commands, secret access and unrelated directory changes.
The expected output is a small diff, a written explanation of what changed and why, and a pass/fail result from the relevant local validation command if you run it. Because this article is researched rather than field-tested, no benchmark result or pass rate is implied.
Step 4: review the diff before wider validation
Before accepting the result, review git diff. If the change touches only the dashboard component and its test, run the smallest relevant test first. If shared code changed, run the broader suite available in the repository. If the tests do not cover the changed behaviour, do not treat a passing lint command as enough. When the fix is ready to leave the local machine, move it through a reviewed branch and pull request rather than letting the agent bypass review; the safe Codex GitHub branch-to-PR workflow covers that handoff.
How to switch permissions in current Codex
In the interactive CLI, OpenAI says users can enter /permissions to open the permissions picker and change the active permissions profile. That is the safest place to inspect what Codex is currently allowed to do before a task changes shape.
The official command reference shows the current startup flags readers should check instead of relying on older mode names.
For command-line startup, OpenAI’s developer command reference documents --ask-for-approval with on-request or never. It also documents --dangerously-bypass-approvals-and-sandbox and --yolo as risky options that run every command without approvals or sandboxing.
For normal local coding, OpenAI recommends:
codex --sandbox workspace-write --ask-for-approval on-request
For restrictive behaviour similar to old untrusted or Suggest-like workflows, use read-only with on-request. The OpenAI Help Center says Codex CLI 0.149.0 and later no longer support approval_policy = "untrusted", and recommends sandbox_mode = "read-only" with approval_policy = "on-request" as the restrictive alternative.
Always confirm your installed codex --help output before using flags. Do not assume --approval-mode suggest|auto-edit|full-auto is supported on your version.
Stop conditions and recovery
Stop Codex, refuse an approval or reset the task when the requested action no longer matches the task you asked for. Common signals include unrelated file changes, a request for danger-full-access without a task-specific reason, global installs for a non-dependency task, unexpected edits to secrets or production configuration, unexplained migration or deployment changes, an already dirty repository, or tests that do not cover the behaviour being changed.
Recovery should be boring: inspect git diff, revert unrelated changes, return to read-only with on-request, and ask Codex to explain the next smallest step before allowing more edits.
For the next concrete task, choose one setup: read-only with on-request for inspection, workspace-write with on-request for clean local edits, or true full access only inside an intentionally isolated environment.