Approve commands by risk
One command, one decision
After this, you'll be able to sort approval requests into safe, inspect first, and reject categories based on what they affect.
Before you start
Complete Read sandbox mode before approving first.
The idea
Approval is not a mood. It is a risk decision. Codex asks because a command crosses a boundary, not because the command is bad. Your job is to understand what changed about the boundary.
- GoalAfter this, you'll be able to sort approval requests into safe, inspect first, and
- InputsLow risk stays inside the workspace and proof loop
- Approve commands by riskEach request is classified by what it can affect
- ReviewMedium-risk requests ask for explanation or narrow approval
- ProofClassify three approval prompts and choose the narrowest useful response for each
Here is the before and after: before, Codex is guessing from a loose request. After, you can sort approval requests into safe, inspect first, and reject categories based on what they affect.
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 (11 min)
Watch out for
- Approving based on command length instead of effect.
- Treating test commands and install commands as the same risk.
- Letting Codex delete files without naming the recovery path.
- Approving broad session access because you want the run to move faster.
Paste this into Claude
Classify these Codex approval requests: Commands or actions: 1. [paste request] 2. [paste request] 3. [paste request] For each, choose: - approve once - approve for session - ask for explanation - reject Give the reason and the follow-up proof you need.
What a good response looks like
npm test -- profile: approve once, local proof command. npm install: ask for explanation, then approve once if package changes are expected. rm -rf public/uploads: reject, destructive and outside task scope.
What good looks like
- Each request is classified by what it can affect
- Medium-risk requests ask for explanation or narrow approval
- High-risk requests are rejected or escalated
- Each approval has a proof step
When this breaks
- Breaks when a command is technically familiar but dangerous in this repo.
- Breaks when a session-level approval lets later commands exceed the original reason.
AI can help with this
Use Codex to help you you can sort approval requests into safe, inspect first, and reject categories based on what they affect. Start with the exercise prompt and your real input. Ask for one draft, then check it against this proof: Each request is classified by what it can affect. Accept only the version you can verify yourself.
You can now
You can classify read, write, network, and destructive actions
- You can request a better explanation
- You can choose approve once by default
- You can reject actions outside scope
Key takeaways
Approve the effect, not the command name. The right approval names what Codex can affect and how you will check it.
- Low risk stays inside the workspace and proof loop.
- Network, install, and broad writes need more inspection.
- Auth, billing, secrets, production data, and destructive git actions are high risk.
- Session approval should be rare and narrow.