Codex CLI approval modes and safety
Codex CLI is more than a wrapper around GPT—it’s a developer agent that can read files, propose diffs, run commands, and even connect to the network. That power makes approval modes critical. They decide how much control Codex has inside your repo.
In this guide, we’ll break down the three modes, show you how to configure them, and share best practices for safe daily use.
Why approval modes exist
Unlike a chat window, Codex works directly in your environment. Without guardrails, it could:
- Modify files you didn’t intend.
- Run commands with side effects.
- Access the network or external APIs.
Approval modes put consent checkpoints in place. You decide how much autonomy Codex has, balancing productivity with security.
The three approval modes
1. Auto (default)
- What it does:
- Can read and edit local files in your repo.
- Can run local commands (like
npm test). - Prompts before touching the network or external resources.
- Best for: everyday development. It’s fast but still asks before stepping outside your repo.
2. Read Only
- What it does:
- Codex can analyze code, generate plans, and discuss ideas.
- It cannot edit files or run commands.
- Best for: design sessions, code reviews, or when you want Codex as an advisor without risk.
3. Full Access
- What it does:
- Removes most prompts.
- Codex edits, runs commands, and makes network calls freely.
- Best for: disposable sandboxes, experiments, or throwaway branches.
- Warning: not recommended for production repos.
Switching modes inside the CLI
Change approval levels on the fly with the /approvals command:
/approvals auto
/approvals readonly
/approvals full
You’ll see confirmation in the terminal showing the active mode.
Persistent configuration
Codex stores settings in a config file:
~/.codex/config.toml
You can:
- Set a default approval mode.
- Apply project-specific overrides.
- Audit and reset configs if behavior feels off.
Pro tip: check this file into onboarding docs so your team shares the same defaults.
Sandbox practices
- Use Auto by default. It balances speed and safety.
- Switch to Read Only when planning or running design reviews.
- Restrict Full Access to Docker containers, throwaway VMs, or experimental branches.
Think of Full Access like sudo—powerful, but only safe in the right context.
Workflow examples
Bug triage
- Start in Read Only.
- Ask Codex to analyze failing tests.
- Switch to Auto for a proposed fix.
- Run your test suite.
- Approve if green.
CI script fix
codex exec "fix the failing build step in .github/workflows/ci.yml"
Runs in Auto mode by default, applying minimal safe changes.
Experiment in sandbox
- Create a new branch.
- Switch approval mode to Full Access.
- Let Codex explore broader changes.
- Merge nothing without review.
Troubleshooting approval issues
- Prompts keep resetting: check
~/.codex/config.tomlfor default mode conflicts. - Codex asks too often: switch from Read Only to Auto.
- Unwanted edits: tighten back to Read Only and review diffs manually.
Security best practices
- Treat approval prompts as a second layer of code review.
- Never use Full Access on repos with production credentials.
- Use environment variables instead of pasting secrets.
- Audit config regularly like you would
.gitignoreor CI scripts.
How this connects to the bigger picture
Approval modes are the safety valves in the Codex workflow. Pair them with:
- The VS Code extension guide for editor-based tasks.
- The complete Codex CLI + VS Code integration guide for a full overview.
- The companion on when to run locally vs delegate to cloud.
Together, these articles give you both the why and the how of safe AI-assisted development.
Conclusion
Codex CLI is powerful enough to change how teams work—but only if you manage permissions wisely. Approval modes let you:
- Move fast with Auto
- Stay safe with Read Only
- Explore freely with Full Access
Set defaults that match your workflow, sandbox when needed, and always review diffs. With that discipline, Codex becomes a reliable teammate instead of a risky experiment.
