Anatomy of a permission prompt

A prompt appears. You skim it. You hit a button. Done.

For most of them, that’s fine — you don’t read every yield sign you drive past either. But you do need to know what each line of the prompt means, because one of them is louder than it looks.

What’s on the prompt

Every prompt tells you three things:

What — the exact command Claude wants to run, or the exact file change it wants to make.
Where — the working directory, or the file path. “Delete a file in /tmp/scratch” is a different action than “delete a file in ~/Documents.”
Why-ish — a one-line label like “Claude wants to run rm” or “Claude wants to edit package.json.”

Read in that order: what it is, where it’s pointed. The second one catches more mistakes than the first. Claude is usually right about the kind of action; the directory is what slips.

The three buttons aren’t equal

The buttons are roughly:

Yes, once — allow this exact thing, this one time.
Yes, always for this kind of action — never ask again about commands like this.
No — deny it. Tell Claude what to do differently.

The middle one is the loud one, and people misread it constantly. It’s not “yes for the next ten minutes.” It’s not “yes for this conversation.” It’s a persistent setting, the same kind your phone uses when an app asks for camera access. You’re not approving the action — you’re handing the action a permanent door key.

“Always allow” is a one-way door. Use it for the things you’d run yourself without thinking, never for the things you’d want to read twice.

A good test

Before clicking “always,” ask: if I’d written this command myself, would I have run it without re-reading? ls, pwd, git status — sure. Anything involving rm, push, network, or anything else that moves things in the world — no.

You can always loosen later. You can’t easily un-grant.

What’s next

You can read a prompt now. But “should I approve this?” still depends on something we haven’t named: how far the action can actually reach. That’s the next word — blast radius.