Approvals
Set Codex approval and sandbox boundaries for team use, including safe defaults, escalation rules, automation exceptions, and review points for risky actions.
Key takeaways
- Set Codex approval and sandbox boundaries for team use, including safe defaults, escalation rules, automation exceptions, and review points for risky actions.
- Use this chapter as a first-pass operating checklist before changing systems, data, permissions, or customer-facing workflows.
- Validate platform-specific details against current official docs or internal policy before rollout.
Approvals define the boundary between autonomous work and human responsibility. A good policy reduces interruptions for safe actions while forcing review for risky ones.
Approval Model
| Action | Default posture |
|---|---|
| Read project files | Allow inside the workspace |
| Edit scoped files | Allow when task scope is clear |
| Run tests and build | Allow with visible command output |
| Install packages | Ask for approval |
| Access network | Ask or restrict by profile |
| Touch secrets or deployment config | Require explicit approval |
Sandbox Strategy
| Mode | Use when |
|---|---|
| Read-only | Review, analysis, audit |
| Workspace-write | Normal implementation |
| Network-limited | Work should not fetch external state |
| Escalated | Rare operations that need broader system access |
Review Questions
- What can Codex change without asking?
- Which commands are allowed in CI or automation?
- What events need a human approval record?
- Can the user understand why approval is requested?