Codex Approval Modes: Suggest, Auto, and Full Access

Codex approval modes decide how much Codex can do on your machine before it has to stop and ask you first. Suggest mode (often surfaced today as read-only or Chat mode) never touches your files or shell without a yes from you. Auto mode, the default for most engineers, edits files and runs commands inside your project automatically but still checks in before it leaves the workspace or touches the network. Full Access removes both guardrails and should be treated like handing someone your terminal and your Wi-Fi password.

This article walks through what each mode actually restricts, how to set them from the command line and from config.toml, how the newer permission model (approval_policy plus sandbox_mode) relates to the older three-name scheme, and which mode makes sense for which kind of work. Everything here is version-agnostic where it matters, since Codex's exact flag names have shifted release to release, but the underlying three-tier idea has held steady.

Two knobs, not one

The biggest source of confusion around Codex approval modes is that people talk about them as a single dial, when Codex actually exposes two independent settings that get bundled together into the "Suggest / Auto / Full Access" story:

• `approval_policy`: when Codex has to stop and ask you before doing something. Values you'll see are untrusted, on-request, on-failure, and never.
• `sandbox_mode`: what Codex is technically capable of doing, regardless of whether it asks. Values are read-only, workspace-write, and danger-full-access.

A "mode" like Auto is really a preset pairing of these two: workspace-write sandbox plus on-request approvals. Full Access is danger-full-access sandbox plus never (or close to it) on approvals. Once you see it this way, the three named modes stop feeling like magic and start feeling like sane defaults you can override individually.

If you've used an older release of the Codex CLI, you may remember the flag --approval-mode with values suggest, auto-edit, and full-auto. That naming maps cleanly onto the same three tiers this article covers, it was just expressed as one flag instead of two. Current Codex builds favor the split approval_policy / sandbox_mode model because it lets you mix and match, for example: auto-approve edits but always ask before network access.

Suggest mode: read-only, ask for everything

Suggest mode is the safest tier. Codex can read your codebase, propose diffs, and draft shell commands, but it will not write a file or execute anything without you explicitly approving each action. In the modern CLI and IDE this shows up as a read-only sandbox, or as "Chat" mode when you specifically want Codex to reason and plan without touching anything at all.

Use Suggest mode when:

• You're exploring a codebase you don't fully trust yet, including a freshly cloned open source repo.
• You want a second opinion or a design review, not code changes.
• You're pairing with someone and want every change narrated and approved out loud before it lands.
• You're running Codex against production infrastructure config and a wrong command could be expensive.

From the command line, start a read-only session like this:

codex --sandbox read-only --ask-for-approval untrusted

Or, if your Codex build still ships the legacy flag:

codex --approval-mode suggest

In config.toml you can make this the default for a specific project or profile:

[profiles.review]
sandbox_mode = "read-only"
approval_policy = "untrusted"

Then launch it with:

codex --profile review

Inside an interactive session, check or change your current posture with the /permissions slash command (older builds used /approvals for the same purpose). Typing /permissions opens a picker so you can drop into read-only mode mid-conversation without restarting Codex.

One thing worth internalizing: Suggest mode still lets Codex read your entire working directory. It is not a network sandbox and it is not a secrets vault. If you have .env files with live credentials sitting in the project root, Codex can see them and reason about them even in read-only mode, it just won't edit or exfiltrate them on its own initiative. Keep secrets out of the working tree or in files your .gitignore and any relevant Codex ignore config already exclude.

Auto mode: the default that does real work

Auto mode is what most people mean when they say "I just let Codex run." It corresponds to sandbox_mode = "workspace-write" with approval_policy = "on-request" (sometimes on-failure, which only interrupts you when a command errors out). In this mode Codex can:

• Create, edit, and delete files inside the current working directory and its subdirectories.
• Run local commands: linters, test suites, package installs, git operations that stay local.
• Iterate on its own output, running a test, reading the failure, and fixing the code, without pinging you between each step.

What it will not do without asking:

• Write outside the working directory (for example, touching your shell profile or a sibling project folder).
• Reach the network, which blocks things like pip install from an untrusted index, curl to an arbitrary host, or pushing to a remote.
• Run a command flagged as dangerous by Codex's own heuristics, even inside the workspace.

Start Auto mode explicitly with:

codex --sandbox workspace-write --ask-for-approval on-request

Legacy equivalent:

codex --approval-mode auto-edit

Note the subtle difference from the old auto-edit name: in the legacy three-mode scheme, auto-edit applied file edits automatically but still asked before every shell command. The modern workspace-write + on-request combination is closer to what most people actually want day to day, since it lets Codex run routine local commands (tests, formatters, builds) without a prompt for every single one, while still gating anything that leaves the workspace.

A config.toml profile for a typical local dev loop looks like this:

[profiles.dev]
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[profiles.dev.sandbox_workspace_write]
network_access = false

That last block is worth calling out: even inside workspace-write, network access is a separate switch. Leaving it false means Codex can edit and run code freely but still has to ask before it can curl, hit an API, or install a new dependency from the internet. Flip it on only for projects where you're comfortable with Codex reaching out on its own:

[profiles.dev.sandbox_workspace_write]
network_access = true

Auto mode is the right default for the bulk of day-to-day engineering work: implementing a ticket, refactoring a module, writing tests, fixing a failing build. It gives Codex enough rope to actually finish a task in one pass instead of stopping every ten seconds, while keeping the blast radius contained to the folder you pointed it at.

Full Access: no sandbox, no prompts

Full Access, sometimes shown as "Agent (Full Access)" in the IDE picker, sets sandbox_mode = "danger-full-access" and effectively turns off approval prompts. Codex can write anywhere on the filesystem it has OS-level permission to touch, reach the network freely, and run commands without checking in first. There's also a blunt escape hatch for automation and container use:

codex --dangerously-bypass-approvals-and-sandbox

The flag name is not subtle on purpose. This is the mode that lets a CI job or a disposable container run Codex unattended from start to finish, which is exactly the use case it's built for. It is also the mode most likely to cause real damage if used casually on your primary machine: a bad command can modify files outside the repo, push to a remote, hit paid APIs, or install packages you didn't ask for, all without a pause for you to catch it.

Use Full Access when:

• Codex is running inside a disposable container or VM that gets thrown away after the job.
• You're running a scripted, unattended pipeline (a nightly migration job, a scheduled goal loop, a CI step) where no human is watching to approve prompts anyway.
• You've already reviewed the task, trust the repo, and the worst-case outcome of an unsupervised run is something you can tolerate and roll back with version control.

Do not use Full Access when:

• You're on your daily-driver laptop with other projects, personal files, browser sessions, or credentials in scope.
• The repository is third-party or freshly cloned and you haven't read through what it might try to do.
• You can't easily undo the blast radius, for example a task that touches a live database or calls a paid, rate-limited, or destructive API.

If you do reach for Full Access outside a container, at minimum run it against a scratch clone of the repo, with any cloud credentials scoped to a throwaway account or a read-only key, and commit or snapshot your work first so a bad run is a git reset, not a support ticket.

A safer middle ground some teams use is danger-full-access for the sandbox but keeping approval_policy at on-failure rather than never. That still gives Codex full filesystem and network reach, but it interrupts you the moment something errors out instead of barreling through silently. It's a reasonable compromise when you want speed but aren't ready to fully let go of the wheel:

[profiles.yolo-ish]
sandbox_mode = "danger-full-access"
approval_policy = "on-failure"

Enterprise and managed-machine constraints

If you're on a company-managed laptop, don't assume Full Access is available just because the flag exists. Organizations can lock down the permission ceiling with a requirements.toml policy file that disallows approval_policy = "never" or sandbox_mode = "danger-full-access" outright. If Codex refuses to honor a flag you're passing, check with your platform or security team before assuming it's a bug, it may be an intentional guardrail.

Choosing a mode in practice

A simple heuristic that holds up across most projects:

• New or unfamiliar codebase, or anything touching production: Suggest / read-only. Let Codex explain itself before it acts.
• Normal feature work, bug fixes, test writing, refactors in a repo you own: Auto. This is where you'll spend most of your time.
• Unattended automation, CI, scheduled jobs, or throwaway containers: Full Access, scoped tightly to that environment and nothing else.

It's also fine, and common, to start a session in Suggest mode to see what Codex proposes for a risky change, then switch to Auto with /permissions once you trust the plan, rather than committing to one mode for the whole session up front.

Common mistakes

Treating Full Access as "the fast mode." Speed comes from good prompts and a well-scoped task, not from removing every safety check. A tightly scoped Auto-mode task usually finishes just as fast as a sloppy Full Access one, minus the cleanup.

Forgetting that network access is a separate switch inside `workspace-write`. Teams sometimes set sandbox_mode = "workspace-write" and are surprised when pip install or a git push silently fails or prompts for approval. Check network_access under the sandbox config before assuming Auto mode is misbehaving.

Running Full Access on a machine with other people's data or unrelated projects on it. danger-full-access is not scoped to the repository you launched Codex from. If your home directory has other client work, personal files, or SSH keys, they're in scope too.

Assuming approval mode replaces code review. Auto and Full Access change how much Codex can do before asking, not whether its output is correct. Diff review before merge stays part of the workflow regardless of approval tier.

FAQ

What's the difference between approval_policy and sandbox_mode? approval_policy controls when Codex has to stop and ask you before proceeding. sandbox_mode controls what Codex is technically capable of doing, independent of whether it asks. Suggest, Auto, and Full Access are just common pairings of the two, not separate systems.

Is Suggest mode the same as the read-only sandbox? Functionally yes for file writes and command execution. Some interfaces also expose a dedicated Chat mode for cases where you want Codex to plan and discuss without proposing file diffs at all, which is an even more conservative variant of the same idea.

Can I let Codex run commands automatically but still block network access? Yes. Set sandbox_mode = "workspace-write" and leave network_access = false under the workspace-write sandbox config. Codex can edit files and run local commands freely, but anything that needs the internet, installs, pulls, pushes, API calls, will still require approval or fail depending on your approval_policy.

What does --dangerously-bypass-approvals-and-sandbox actually do? It's the blunt, single-flag way to run Codex with no sandbox restrictions and no approval prompts, equivalent to Full Access with approval_policy = "never". It's intended for containers and unattended automation, not interactive use on a personal machine.

How do I switch modes without restarting Codex? Use the /permissions slash command inside an active session (older builds used /approvals). It opens a picker so you can move between read-only, workspace-write, and full-access postures mid-conversation.

Why did my organization block Full Access even though the flag works locally? Managed environments can enforce a policy ceiling through a requirements.toml that disallows approval_policy = "never" or sandbox_mode = "danger-full-access" regardless of what you pass on the command line. That's an intentional org-level guardrail, not a bug.

Is Auto mode safe to leave on by default? For repos you own and trust, yes, it's the intended default for most engineering work. The main thing to double-check is whether network access is enabled under the workspace-write sandbox, since that determines whether Codex can reach out to install packages or call external services without asking.

Does approval mode affect which model Codex uses or how good its output is? No. Approval mode is purely a permissions and safety layer. It has no effect on reasoning quality, it only changes how much Codex can do unsupervised before checking in with you.