Widening & Bypassing Access Safely

You already know the core safety model from the previous lesson: sandbox = WHERE Codex can read, write, and reach the network (OS-enforced); approval = WHEN it has to stop and ask you. They're independent dials, and the Auto preset (workspace-write + on-request) is the sensible local default.

This lesson is about the moment that default isn't enough. Codex needs to write to a directory outside your project, or hit a package registry, or run unattended in CI — and it's pausing to ask, or refusing outright. The instinct is to reach for the biggest lever: drop the sandbox entirely, or pass --yolo. Resist it.

The right mental model is a least-privilege staircase. When a task is blocked, climb exactly one step — grant the one directory, allow the one domain, flip one approval — never jump to the top. The cost of over-granting isn't hypothetical: Codex runs model-generated commands, and a prompt injection in a web page, a dependency, or an MCP tool result can turn "full access" into "deletes files / exfiltrates secrets." The sandbox is your primary defense against exactly that, so you widen it deliberately and narrowly.

Think of it as three escalating tools, in order of preference:

1. /permissions — change posture for this session without restarting.
2. --add-dir — grant one more writable directory while keeping the sandbox on.
3. --yolo — turn everything off. Reserved for hardened VMs. Almost never the answer.

You don't have to kill your session and relaunch with new flags every time the task's needs change. /permissions switches Codex's approval/sandbox posture mid-session — it's the picker for "set what Codex can do without asking first."

A typical flow: you start in Read Only to let Codex explore and propose a plan you trust, then run /permissions and bump up to Auto so it can actually make the edits — all in the same thread, with all the context it already gathered intact.

/permissions        → opens the posture picker
  Read Only         (read-only + on-request)  — browse & plan
  Auto   (default)  (workspace-write + on-request)  — edit in workspace
  Full Access       (danger-full-access + no approvals)  — not recommended

Two naming gotchas the dossier is explicit about:

• /permissions replaced /approvals. Older tutorials, videos, and even some slice titles still say /approvals — it is no longer a distinct entry. Use /permissions.
• /approve is a different command. It approves one retry of a recent auto-review denial (covered later in this lesson) — it does not switch your posture. Don't confuse the two.

To see your current posture at any time, run /status, which shows workspace dirs, context usage, rate limits, and the thread ID.

Here's the single most useful move in this lesson. When Codex needs to write somewhere outside your workspace — a shared cache, a sibling repo, a generated-assets folder — the wrong fix is to drop to danger-full-access. The right fix is to grant just that path:

# Grant one extra writable directory; sandbox stays ON everywhere else
codex --sandbox workspace-write --add-dir ../shared-assets

# Repeatable — grant several without ever removing the boundary
codex --add-dir ../shared-assets --add-dir /tmp/build-cache

--add-dir <path> is repeatable and is explicitly preferred over dropping to danger-full-access. Every directory you don't list stays protected by the OS-level sandbox, so a misbehaving command can't wander off and touch your home directory or /etc. You've widened the hole by exactly one directory.

A sibling flag controls where the agent starts: -C / --cd <path> sets the working directory before the agent runs. This is how you point Codex at the right place in a monorepo (open the directory that holds the .codex folder) without granting write access to the whole tree.

If the same extra directory is needed every run, persist it in ~/.codex/config.toml under [sandbox_workspace_write] writable_roots = [...] rather than typing the flag each time — but the principle is identical: name the directory, keep the sandbox.

Alongside the legacy sandbox_mode, Codex ships a newer permission profiles system that expresses least-privilege filesystem and network rules more granularly. Built-in profiles:

Filesystem access levels are read, write, deny — and the conflict rule is the one to memorize: deny wins, and more-specific entries override broader ones. So you can grant write to a whole tree and then carve out a deny on a secrets folder inside it, and the deny holds. Network rules work the same way as a per-domain allowlist where deny overrides allow.

# Newer permission-profile schema (illustrative)
[permissions.my-profile.network]
enabled = true

[permissions.my-profile.network.domains]
"api.openai.com"        = "allow"
"*.internal.example.com" = "allow"
"tracking.example.com"   = "deny"   # deny overrides allow

The compatibility trap — and it's the one most likely to bite you: permission profiles do NOT compose with the older sandbox_mode / [sandbox_workspace_write] settings. The docs are blunt: "Choose one system per session." Mixing a sandbox_mode = "workspace-write" with [permissions.*] rules doesn't merge them into something stricter — it produces confusing, version-dependent behavior. Pick one model and stay in it.

There's a middle ground between "approve every single command yourself" (slow) and "approve nothing" (-a never, blind). Auto-review routes eligible approval requests to a reviewer agent instead of interrupting you for each one.

You enable it by setting approvals_reviewer = "auto_review" (the alternative is the default "user"), configured via an [auto_review] section with a policy. When a command would normally prompt you, the reviewer agent evaluates it first, specifically screening for:

• Data exfiltration — sending your code or secrets somewhere
• Credential probing — fishing for API keys, tokens, .env files
• Persistent security weakening — disabling protections, opening backdoors
• Destructive actions — rm -rf, dropping data, force-pushes

If the reviewer flags something it denied, /approve lets you approve one retry of that recent auto-review denial — this is the command from the earlier gotcha, and now you can see why it exists. In managed/enterprise setups, a guardian_policy_config can override the local [auto_review].policy, so org defaults win over individual config.

Auto-review is a productivity-and-safety layer, not a license to remove the sandbox. It reduces approval fatigue while keeping a screen on the dangerous stuff — but it's still the sandbox, not the reviewer, that physically stops a harmful command from reaching your filesystem.

Finally, the lever this lesson's title warns about. --dangerously-bypass-approvals-and-sandbox — alias --yolo — disables both controls at once. No approvals, no sandbox. Every command Codex generates runs with your full user permissions, with full filesystem and network access.

The name is the documentation. There is exactly one defensible use: inside an externally hardened container or throwaway VM where the blast radius is already contained by something other than Codex — and even then, prefer the narrower tools first. On your real machine, against a repo you care about, --yolo is how a single prompt injection becomes a very bad day.

A related, easily-confused flag: --full-auto is deprecated. It used to be a shortcut for --sandbox workspace-write + --ask-for-approval on-request (the Auto preset). It now prints a warning; prefer setting -s and -a explicitly so your posture is unambiguous. Don't read "full-auto" as "full access" — historically it stayed inside the workspace sandbox; it's --yolo that removes the boundary.

Note the OS won't quietly help you here either: if a platform can't enforce the sandbox you asked for, Codex refuses to run rather than silently dropping to no-sandbox — so an unsandboxed run is always something you chose, explicitly, with a flag like this one.