Read sandbox mode before approving
Know the boundary Codex is working inside
After this, you'll be able to explain workspace-write, read-only, danger-full-access, and why approval policy is separate from sandbox mode.
Before you start
Complete Pick the right sign-in path first.
The idea
Sandbox mode says what Codex can touch. Approval policy says when it must ask. Those are different controls, and you need both before you trust an agentic coding run.
| Ready | Needs work | |
|---|---|---|
| Job fit | The answer separates sandbox from approval | The task is still vague |
| Proof | The command's effect is named | The result is assumed |
| Risk | Low | Breaks when Codex can write outside the intended project because the sandbox boundary |
| Next move | Continue | Clarify first |
Use Ready only when the proof is visible.
Here is the before and after: before, Codex is guessing from a loose request. After, you can explain workspace-write, read-only, danger-full-access, and why approval policy is separate from sandbox mode.
Now try it use the exercise prompt on one real repo task. Keep the output small enough to check before you accept the change.
You are ready when the Codex action, boundary, and proof all match the task.
Try it (12 min)
Watch out for
- Confusing no approval prompts with no risk.
- Using danger-full-access because a task is blocked once.
- Approving network access without knowing why it is needed.
- Approving for the session when one command would be enough.
Paste this into Claude
Audit this Codex run before approving commands: Surface: [app, CLI, IDE, cloud] Sandbox mode shown: [read-only, workspace-write, danger-full-access, unknown] Approval policy shown: [on-request, never, granular, unknown] Command requesting approval: [paste command] Why Codex says it needs it: [paste reason] Return: 1. What the sandbox allows. 2. Why approval is being requested. 3. The safest response: approve once, approve for session, reject, or ask Codex to revise.
What a good response looks like
Workspace-write allows edits in the repo. Approval is requested because npm install needs network access. Approve once only if dependency install is part of the task and package files will be reviewed. Otherwise ask Codex to explain why install is needed.
What good looks like
- The answer separates sandbox from approval
- The command's effect is named
- Network or outside-workspace access is treated as higher risk
- The safest approval scope is selected
When this breaks
- Breaks when Codex can write outside the intended project because the sandbox boundary was loosened too far.
- Breaks when approval policy is set to never for an interactive high-risk task.
AI can help with this
Use Codex to help you you can explain workspace-write, read-only, danger-full-access, and why approval policy is separate from sandbox mode. Start with the exercise prompt and your real input. Ask for one draft, then check it against this proof: The answer separates sandbox from approval. Accept only the version you can verify yourself.
You can now
You can explain sandbox mode
- You can explain approval policy
- You can classify a command by risk
- You can choose the narrowest useful approval
Key takeaways
Sandbox and approvals are separate controls. Read both before you let Codex act.
- Sandbox mode defines technical reach.
- Approval policy defines when Codex pauses.
- Workspace-write is the normal local work boundary.
- Danger-full-access needs an isolated environment.