Each shell command is classified by its effect before it runs. Read-only commands run freely, writes need approval, and a few are always refused.
The agent proposes
$git statusRead&&rm -rf ~Irreversible deletion
Earlier in this session
Security-conscious teams who want to know exactly what a coding agent will do before it touches the file system or runs destructive commands.
Every shell command is classified by its effect before it runs.
Absolute refusals hold in every mode, so auto-approve never lets them through.
Reads run without asking, while writes and riskier commands open a prompt first.
Before a command runs, ML.ai lexes it, works out what it would do, and decides whether to run it, ask you first or refuse it outright.
git log --oneline -5-> read
cat package.json-> read
npm install zod-> write
git push --force origin main-> asks
Each command gets an effect
The command is lexed into its parts and judged by its effect on your machine. Reads run straight away, while writes and riskier effects wait for you.
read: runsgrep -rn TODO src/
write: asks firstgit checkout -b fix/cache
refusedrm -rf /
Reads run, writes ask, a few never run
A read like grep or git log runs without a prompt. A write, or anything riskier, opens a permission prompt so you can allow it once, always or deny it.
“Just tidy up the repo”
# effects: read + write
git status && git clean -fdx
# verdict: write, needs approval
# effects: read + write
git status && git clean -fd dist/
# verdict: write, needs approval
Denied, narrowed, checked again
Deny a broad command and say why. Your reason is passed back to the model, which can propose a narrower command that goes through the same check.
Proposed: rm -rf / --no-preserve-root
Auto-approve is on
Refusals hold even under auto-approve
A few commands are refused outright in every mode, auto-approve included. No prompt appears, nothing runs, and the agent has to take another route.
Matches words in the command, so it blocks a search and misses a delete
classifierA list of banned strings misses the variant nobody thought of, and blocks harmless commands that happen to contain a scary word somewhere in an argument.
ML.ai lexes the command and works out what it would do. A read runs, a write or riskier effect asks first, and the short refusal list stops the rest.
Here is what happens to a command between the agent proposing it and your shell running it.
· BuildStaged changes look good, committing now
Proposed command
git status && git commit -m "fix: cart total"
· BuildStaged changes look good, committing now
Lexed into parts
· BuildStaged changes look good, committing now
Verdict: write, asks first
git statusRead
git commit -m "fix: cart total"Write · asks
· Buildrm -rf /
Refused: on the absolute list
No prompt appears and nothing runs, so the agent takes another route.
· BuildStaged changes look good, committing now
Proposed command
git status && git commit -m "fix: cart total"
What to know about how commands get classified.
What goes wrong
How handles it
A prompt for every ls and grep trains you to click Allow without reading, which defeats the point of asking.
How handles it
Reads never prompt, so the prompts you do see are for writes and riskier effects that deserve a look.
A destructive step tucked after && or inside a pipe can slip past a check that only looks at the first word.
How handles it
The whole command is lexed, chains and pipes included, and judged by what each part would do.
Turning on auto-approve to move faster can mean a destructive command runs with nobody watching.
How handles it
The short list of absolute refusals holds in every mode, auto-approve included, so those commands never run.
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;
12@@ -12,3 +12,3 @@ export type Invoice
13- userId: string;
13+ accountId: string;
14 amount: number;
Three answers on every prompt
How Allow, Always and Deny work, and how you see the real diff before any edit lands.
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
Plan mode denies edit and write tools for the turn while still letting tests and typecheckers run.
You can choose Always on a write prompt so that command stops asking. The absolute refusal list works differently: it holds in every mode, auto-approve included, and nothing lets those commands through.
Reads like ls, cat, git status and grep never prompt. Test runners and typecheckers also run without a prompt, even in Plan mode; that trust is by name, so the classifier recognizes npm test without inspecting what the script does.
A short list of absolute refusals: deletion outside the workspace, writes to devices or system roots, privilege escalation, fork bombs, reading credentials into a command that reaches the network, and anything whose program can’t be identified before running. It holds regardless of mode, agent or setting, auto-approve included.
Your reason is passed back to the model rather than a bare rejection, so it can propose a narrower command instead of retrying the same one. The new command goes through the same check.
Every position where a program could appear is walked, including pipelines, subshells and wrappers like sudo, xargs and timeout. The worst verdict in the chain wins, and a refusal names the part it objects to: git status && rm -rf ~ is refused for the rm -rf ~.
Every command is classified by effect before it runs, so reads move fast, writes wait for you, and the worst never run.
