Bonus 06 of 07
Permissions and safety rules before you let Codex touch your files
Goal: Before Codex edits any file, you should pass four checks: task clarity, file list, risk level, and a final approval decision. This lesson teaches you a visible risk scale, exact approval and rejection prompts, and how to ask for a smaller plan when a task feels too large.
What to do
Understand read actions versus write actions
Every Codex action falls into one of two categories: read or write. Read actions are safe — Codex is looking at files but not changing them. Write actions are where risk begins — Codex is creating, editing, or deleting files. The safety principle is simple: approve read actions freely, but confirm every write action against your checklist before it happens. Ask Codex to separate its plan into read steps and write steps so you can see exactly where the risk is.
Apply the risk scale before approving any write action
Before approving a write action, classify the risk. Use this scale:
RISK SCALE — run this before approving any Codex write action
LOW RISK
- Changing visible text (button labels, headings, paragraphs)
- Adding a new page with no database connection
- Updating a style value (color, font size, spacing)
- Adding an image or replacing an existing one
Rule: review the diff after, then approve
MEDIUM RISK
- Adding a new form or input field
- Changing a route or URL path
- Editing navigation structure
- Adding or removing a dependency (npm package)
Rule: inspect the plan carefully, ask for file list, review diff before and after
HIGH RISK — always ask for a smaller plan first
- Any change to authentication or login logic
- Any change to payment or billing code
- Any SQL query that modifies or deletes data
- Any change to environment variables or .env files
- Any change to build config (next.config.js, tsconfig.json, etc.)
- Any change to security rules (RLS policies, middleware, CORS)
Rule: stop, split the task, approve only one small piece at a timeConfirm the file list before approving anything
Before you say "go ahead," ask Codex to name every file it plans to touch. Then compare that list to your task. The list should only contain files that are directly related to what you asked. If a file appears that you did not mention or expect, stop and ask why. This check catches the most common non-developer accident: approving a change that was much larger than intended.
Use the approval checklist before saying "go ahead"
Run through these four questions before typing any approval. All four must be yes before you proceed. If any answer is no, do not approve — ask for a smaller plan instead. Question 1: Do I understand what will change in plain English, (not "Codex said it was fine" — can you explain it yourself?) Question 2: Is the file list limited to files I expected? Question 3: Is the risk level low or medium — or have I split a high-risk task into a safe first step? Question 4: Is there a branch in GitHub Desktop for this session? If all four are yes, type your approval. If any are no, go to Step 5.
Write a "stop and reduce scope" message when a task is too large
When a task fails the checklist, you need a clear, firm message that stops Codex and asks for a narrower plan. Here are two copy-paste messages you can use.
STOP AND REDUCE SCOPE — use this when the task is too large or risky:
"Stop. This plan is larger than what I asked for. I only want [DESCRIBE THE SPECIFIC PART YOU DO WANT]. Please write a new plan that covers only that one change and names only the files directly needed for it. Wait for my approval before doing anything."
---
STOP AND REDUCE RISK — use this when a high-risk file is included:
"Stop. This plan includes [NAME THE HIGH-RISK FILE OR AREA]. That area is off-limits for this session. Please rewrite the plan without touching [NAME IT AGAIN]. If the task cannot be done without touching that area, tell me — and we will plan it separately in a future session with a clearer safety process."Check GitHub Desktop after every approved session
After every Codex session where you approved write actions, open GitHub Desktop before closing anything else. Look at the changed-files panel on the left. Every file listed should match your approved file list from Step 3. If any extra file appears, right-click it and choose Discard Changes. If the changes in your approved files look different from what you expected, read the diff carefully before committing. Only commit when every change in the diff is something you consciously approved.
Expected result
You can classify any Codex action as read or write, apply the risk scale to your task, confirm the file list before approving, pass the four-question approval checklist, and use the stop-and-reduce-scope messages when a plan is too large.
Key takeaway
- The approval checklist is not bureaucracy — it is the difference between a session that goes exactly where you wanted and one that surprises you with changes you did not ask for. Run it every time.