I had chosen "Always Proceed", and the agent asked again whether it could run a command. By the third prompt I had stopped typing and was wondering whether to close the window.
It is natural to suspect that the setting is broken. Similar reports show up on the official forum. But before chasing the cause, there is something that makes the whole situation easier to live with.
Decide how loose to go by the kind of command, not by the name of a setting. Below is how I draw that line, plus a small script that sorts your approval log.
There are two reasons you get asked
I now think of the prompts as having one of two causes.
The first is that the setting really is not taking effect: a version bug, or the setting being saved in one place and read from another. That is on the product side, and you cannot fix it yourself.
The second is that the setting works, but this particular command was never inside the range you allowed. That one you can calm down just by redrawing the range.
Telling the two apart on the spot is surprisingly hard. So I keep my own line ready for the days I cannot tell. With a line in hand, I can answer each prompt calmly: this one is fine, this one should always ask.
Menu labels and the number of options differ between versions, so I will not rely on exact wording here. Please check your own screen.
Three kinds of commands
| Kind | Examples | My rule |
|---|---|---|
| Read-only | ls, cat, grep, git status | No need to ask |
| Writes locally | mkdir, sed -i, npm run build | Ask each time (loosen per folder once familiar) |
| Deletes, sends, changes permissions | rm, curl, git push, sudo | Always ask |
The point is not to hand all three kinds to one option called "Always Proceed". Being asked about every read-only command wears you down, and a worn-down person starts pressing approve mechanically. That is the riskiest state of all. Loosen the delete-and-send commands along with the rest, and irreversible actions run without a pause.
A script that sorts your approval log
To see what I actually allow, I jot down the commands from each approval prompt and feed them to this script. It solves one problem: showing the share of commands that did not need asking, so you can judge whether your range is reasonable. Standard library only.
#!/usr/bin/env python3
"""classify_cmds.py — sort approval-log commands into auto / ask.
Usage: python3 classify_cmds.py commands.txt (one command per line)
A rough first-word check; treat the output as a starting point."""
import sys, shlex, collections
READ_ONLY = {"ls", "cat", "head", "tail", "grep", "rg", "find", "pwd", "wc", "diff", "tree", "which"}
GIT_READ = {"status", "log", "diff", "show", "branch", "blame"}
LOCAL_WRITE = {"mkdir", "touch", "cp", "mv", "sed", "tee"}
RUNNERS = {"npm", "pnpm", "yarn", "pytest", "python3", "node", "make"}
ALWAYS_ASK = {"rm", "curl", "wget", "ssh", "scp", "sudo", "chmod", "chown", "kill", "dd"}
GIT_RISKY = {"push", "reset", "clean", "checkout", "rebase", "commit"}
def classify(line):
try:
t = shlex.split(line)
except ValueError:
return "ask", "unbalanced quotes"
if not t:
return "skip", ""
# chaining or substitution means the first word alone is not enough
if any(x in line for x in ("|sh", "| sh", "| bash", "$(", "`", "&&", ";")):
return "ask", "chained or substituted"
c = t[0]
if c in ALWAYS_ASK:
return "ask", f"{c} deletes, sends, or changes permissions"
if c == "git":
sub = t[1] if len(t) > 1 else ""
if sub in GIT_READ: return "auto", "git read-only"
if sub in GIT_RISKY: return "ask", f"git {sub} affects history or remotes"
return "ask", "other git operation"
if c in READ_ONLY: return "auto", "read-only"
if c == "sed" and "-i" in t: return "ask", "sed -i overwrites"
if c in LOCAL_WRITE: return "ask", "modifies local files"
if c in RUNNERS: return "ask", "depends on what the script does"
return "ask", "unknown command"
if __name__ == "__main__":
rows = [l.rstrip("\n") for l in open(sys.argv[1], encoding="utf-8") if l.strip()]
tally = collections.Counter()
for l in rows:
k, why = classify(l)
tally[k] += 1
print(f"{k:5} | {l[:48]:48} | {why}")
total = sum(tally.values())
print(f"\ntotal {total}: auto={tally['auto']} ask={tally['ask']}")
print(f"no-ask share: {tally['auto']/total:.0%}")I pushed unknown commands to the ask side on purpose. A design that waves through anything it cannot classify turns every oversight into an incident.
Running it on fifteen lines
For a test I wrote a sample list of 15 commands I commonly see. It is not a real approval log, just a list made for this article.
The result: 7 of 15 were fine without asking, 8 should ask, a 47% no-ask share.
Two things stood out. npm run build and npm test land on the ask side. Being asked every time feels tedious to me, but those can run anything package.json says. They are worth loosening only for a repository whose scripts you have read yourself.
The other was pipes. cat logs/app.log | head -50 passed as read-only, while | sh or && pushes a line straight to ask. The script only looks at the first word, so it cannot see a dangerous command hiding on the right side of a pipe. Treat it as a rough tool and keep the final call with you.
Three questions before pressing approve
Even with a line drawn, a prompt on screen makes me hurry. So before pressing the button I ask myself three things.
First: does this only read, or does it change something? The first word and options such as -i or -rf usually settle it.
Second: can I undo it? Local edits can be reverted if the folder is under version control. Deletes and anything sent outside may not come back.
Third: is it chained? With && or ;, a harmless first word can have something else waiting behind it. That is also why the script above pushes chained lines to the ask side.
Answering takes under ten seconds, and I regret far less than when I press without answering.
Loosen from the narrow end
My order is this. First, put read-only commands on the allowlist; that removes the most prompts. Next, allow build and test for one repository, limited to that folder. The delete-and-send group I leave alone, even on days when I am not at my best.
Loosen by the kind of command, not by the name of a setting. Keeping that line stops me from flipping everything to allowed on the day the setting seems broken.
Your next step
Copy about ten commands from your latest approval prompts and run them through the script. The no-ask share tells you roughly how many of your prompts are read-only. As for why the setting did not take effect, check the changelog for your version and the relevant forum thread. I repeat the same check whenever a version changes.