Codex CLI Full Access: Permissions, Approvals, and Boundaries

Full access in Codex CLI means running with the full-auto approval policy: the agent writes files and runs shell commands without pausing for your review at each step. It is the most autonomous way to run the tool. Whether that is the right setting depends on how precisely the task is scoped and whether the actions are reversible.

The runtime controls, which policy you set and which sandbox the agent runs in, live inside Codex CLI. The decision about which tasks are safe at full access, and the record of what was approved and what happened, lives outside it. A tool like fenbs keeps those human-approved limits and outcomes where every future session can read them.

What changes when you give full access

At the default suggest policy, Codex CLI shows you each proposed file write and shell command and waits for you to confirm. Full access, via --approval-policy full-auto, removes those confirmation steps. The agent works from start to finish without pausing.

This changes three things: speed (sessions complete faster without manual confirmations), oversight (you do not see individual steps as they happen), and risk (a mistake propagates until the session ends or hits an error). Full access makes sense when all three of those trade-offs are acceptable for the task.

The sandbox is a separate control from the approval policy

Codex CLI runs in a sandbox on macOS (using Apple's sandbox framework) and on Linux (using Docker or Podman). The sandbox restricts what the agent can reach: it limits network access and filesystem access to the project directory by default.

Full access in the approval sense, meaning full-auto, does not disable the sandbox. The sandbox is a separate layer of control. The agent may write files and run commands without asking you, but it is still confined to what the sandbox allows. Giving full access to the approval policy does not give the agent access to your entire filesystem or the internet.

Check the OpenAI Codex documentation↗ (opens in a new tab) for the sandbox configuration for your platform, since the defaults and the configuration options differ between macOS and Linux.

When full access is the right choice

Full access is appropriate when the task is precise, the scope is narrow, and the outcome is easy to verify and reverse. A rename across a codebase, a formatting pass, or a dependency update are good candidates: each produces a clear diff you can review with git diff before committing, and git revert handles a mistake.

Full access is less appropriate when the task has broad scope, when the actions involve external systems, or when a mistake is difficult to undo. Submitting a form, sending a notification, or running a migration on a live database are tasks where the confirmation step exists for a good reason.

When to use narrower boundaries instead

Narrower execution boundaries are the right choice whenever the cost of a mistake exceeds the benefit of skipping the confirmation. Three situations where a narrower policy is better:

• New type of task: run it in suggest mode first so you can see each step and verify the agent's approach before removing the checkpoints.
• Tasks that affect external state: anything that writes to a database, calls an external API, sends a message, or deploys code should use suggest regardless of how straightforward it seems.
• Shared repositories: on a branch that other people are working on, pausing before commits gives teammates a chance to catch scope drift before it reaches the shared history.

The auto-edit policy is a useful middle ground: file writes proceed without confirmation, but shell commands still pause. For code-editing tasks where you trust the agent's file changes but want a checkpoint on commands, auto-edit gives speed without removing all oversight. See codex cli auto mode for a full comparison.

Set a restore point before a full-access session

Before running at full access, take a Git checkpoint:

git commit -m "checkpoint before full-auto codex session"
# or
git stash

After the session ends, review the diff: git diff HEAD~1 if you committed, or git diff if you stashed. Commit the result if it looks correct. The codex cli undo guide covers how to recover if you need to revert.

Record approved limits and outcomes

When you decide that a specific type of task is safe at full access, record that decision. Include which types of task qualify, what the scope restriction is, and any conditions that would require dropping back to a narrower mode.

Record the outcome of each full-access session on the task: what was run, what was reviewed in the diff, whether it was committed, and any unexpected behavior. This record is more useful than a Git commit message because it captures the review step, not just the result.

If the session produced an unexpected result, record it as a Lesson. The codex cli best practices guide covers the full framework for scoping and reviewing automated runs.

How to do this with fenbs

1. Create a free account and add the task you plan to run at full access. Write the goal, scope, and completion criteria as the plan.
2. Add a Decision to the project: which task types are cleared for full access, under which conditions, and what always requires suggest mode.
3. Connect Codex CLI from Integrations. At the start of each session, it reads the Decisions and rules before it starts work.
4. Take a Git checkpoint before the full-access run. After it ends, review the diff and commit if it looks correct.
5. Update the task in fenbs with the outcome: what was run, what was verified, and whether anything unexpected happened.