Every edit and command goes through one approval gate. You see the real diff first, then allow it once, always, or deny it.
Found the refresh path. Updating the session helper now.
GreprefreshToken · 6 matches in app/auth
Fs.readapp/auth/session.ts
Fs.writeapp/auth/session.tspending
app/auth/session.ts2 lines changedlines 42-50
42export async function refresh(token) {
43 if (!token) return null;
44 if (!token?.exp) throw new Error('expired');
45 return await rotate(token);
46}
47
48async function rotate(token) {
49 const next = await issue(token.sub);
50 return next;
Developers and teams who need full control over what an AI coding agent writes to disk, with reviewable diffs before every change.
See the real diff before any edit lands, then choose Allow, Always or Deny.
Keep migrations, auth and config on Allow so each change gets a fresh look.
Use Always for routine edits so the prompts that remain are worth reading.
Each edit and command stops at one gate. You see the real diff, choose Allow, Always or Deny, and a denial goes back to the model with your reason.
12@@ -12,3 +12,3 @@ export type Invoice
13- userId: string;
13+ accountId: string;
14 amount: number;
Three answers on every prompt
Allow lets this one change through. Always stops asking for that kind of change. Deny blocks it and sends your reason back to the model.
▾src
·invoice.tsM
·charge.tsM
·refund.tsM
accountId: string;
const { accountId } = invoice;
lookupAccount(invoice.accountId);
One prompt per edit, each with its diff
The prompt opens the exact change the agent wants to make, file by file, so what you approve is the code that will land on disk.
Rename it in the tests too
accountId: 'u_123',
});
Waiting for your approval
Diff shown, change waiting
The request is one line and the diff is what lands. Reading both side by side is how you catch a change that goes further than you meant.
Why are you denying this edit to 0042_rename.sql?
Deny with a reason
Denials go back with the reason
When you deny, your reason is passed back to the model, so the next attempt works around it instead of proposing the same edit again.
Edit src/cart.ts?
-return subtotal
+return subtotal - discount
Lets this change through and asks again next time
Format src/utils/date.ts?
-const d=new Date( ts )
+const d = new Date(ts)
Approves this kind of change from now on
Allow lets one change through and asks again next time. Deny blocks it and sends your reason to the model. Use these while you learn how the agent works in a repo.
Always approves that kind of change from then on, which saves clicks on routine edits. Keep it for changes you would approve every time and off paths you want to review.
Always saves time, and it also widens what runs without you. Here is a sensible way to use it.
Edit src/cart.ts?
-return subtotal
+return subtotal - discount
Format src/utils/date.ts?
-const d=new Date( ts )
+const d = new Date(ts)
Approves this kind of change from now on
Edit migrations/0042_rename.sql?
-user_id TEXT NOT NULL
+account_id TEXT NOT NULL
Sensitive path: answered one at a time
Format src/utils/date.tsAlwaysRevoke
Format src/utils/money.tsAlwaysRevoke
Edit files in src/AlwaysRevoke
Each rule can be revoked on its own
Edit src/cart.ts?
-return subtotal
+return subtotal - discount
Habits that make approval prompts work for you.
What goes wrong
How handles it
After a dozen prompts it is easy to click Allow on reflex and miss the one change that went too far.
How handles it
Reads never prompt, so what reaches you is an edit or a riskier command, shown as its real diff or the command itself.
A broad Always set early in a project keeps approving changes long after you would have wanted to see them.
How handles it
Use Always only for routine changes and keep sensitive paths on Allow, so the risky edits still come to you one at a time.
Blocking a change without saying why often brings back the same edit on the next try, slightly reworded.
How handles it
A denial is passed back to the model with your reason, so the next attempt can take it into account.
The agent proposes
$git statusRead&&rm -rf ~Irreversible deletion
Earlier in this session
git log --oneline -5-> read
cat package.json-> read
npm install zod-> write
git push --force origin main-> asks
Each command gets an effect
How each shell command is classified by effect before it reaches a permission prompt.
Fix the registration validation bug and run the relevant tests.
plan.md
Fix registration validation
Ask ML.ai...
PLAN.md · image uploads
## Step 1: add an uploads queue
- create src/jobs/resizeImage.ts
- enqueue from POST /uploads
- test: jobs/resizeImage.test.ts
The plan, written as steps to review
Get a plan first with edit and write tools denied, then switch to Build and approve changes one diff at a time.
Open the saved-permissions list, where every saved rule appears individually, and revoke that one on its own. The next matching change goes back to asking for Allow, Always or Deny.
Every edit, and every command except reads. Reads run without asking, so prompts stay rare enough to read properly.
It approves that kind of change from then on, so keep it for routine edits and away from migrations, auth and config. In a Git repository the rule is scoped there; in a folder that is not a Git repository it is saved globally, across every non-git folder you open on that machine.
Plan mode denies edit and write tools for that turn, so you get a plan back with no file writes to approve.
Shell commands have no diff, so the prompt shows the command itself after it has been classified by effect. Reads skip the prompt altogether.
See the real diff, answer Allow, Always or Deny, and send your reason back to the model when you say no.
