Deciding what to approve

The permission system is the mechanism: which actions stop and ask, which modes exist, how to loosen them. This page is the part the mechanism can’t do for you — deciding, when a prompt is actually in front of you, whether the answer is yes.

It matters more than it sounds, because the failure mode isn’t declining something you should have approved. It’s the opposite: a hundred harmless prompts train you to click approve, and then prompt one hundred and one isn’t harmless and gets the same reflex. The whole skill is keeping the small number of prompts that deserve attention from disappearing into the noise of the ones that don’t.

Read the location before the action

The first move is unglamorous: actually read what’s being proposed. Not the kind of action — the specific one. The command, and above all the path.

That ordering is deliberate, and it’s the single most useful habit here. “Delete notes.txt” is the same six words in three different places:

• in a scratch folder you made yesterday — nothing of value is lost;
• in a project you haven’t committed yet — that may be an hour of work;
• somewhere in your documents — something else may have depended on it.

The action didn’t change. The action never tells you the risk; the location does. If you can’t tell what a prompt would do, you’re not ready to approve it — which is a complete and respectable answer, not a gap in your knowledge.

How far do the consequences reach?

Blast radius: how far the consequences of an action can reach if it goes wrong.

It sorts onto a ladder, smallest to largest, and after a week you’ll place things on it without thinking:

1. Just this chat. Claude reasons something through, drafts a note, sets something up for the conversation. Nothing outside the chat moves.
2. A scratch file. A throwaway file in a folder only you use.
3. Your project. Editing files, installing a package — anything inside one folder you can roll back.
4. Your machine. Files outside the project: your settings, your documents, things other apps depend on.
5. Other people. Pushing code, sending an email, calling a paid service, posting to a channel. The internet doesn’t forget.

The top rungs you approve and move on. The bottom rung is where you stop and actually read.

One addition people miss: reading is blast too. If Claude reads a file full of credentials, customer records or salary data, those contents are now in the conversation — and conversations get copied, shared, and logged. “Just reading” sounds like rung 1 and is often rung 4 or 5. That’s the seam where this page meets company data and privacy.

Can you take it back?

Blast radius asks how much. The sharper question asks whether you get it back at all.

A one-way door is an action you can’t easily undo. Once it’s through, it’s through.

Two-way doors — take your time, but don’t agonise: editing a file, creating one, running a build or a test, installing a package. All reversible.

One-way doors — read twice: sending anything to another person or system, pushing to a branch other people use (especially a force-push), deleting something you have no backup of, dropping database tables, anything that costs money, anything that crosses the network into someone else’s system.

So before approving anything that isn’t a plain file edit:

If this turns out to be wrong, can I take it back?

Yes → approve and move on. Speed is fine in a hallway full of two-way doors. No → slow down, read what it’s about to do, and consider asking for a safer version.

The two questions stack rather than overlap. A failing test has zero blast radius and is fully reversible. Deleting your only copy of an unsaved file has a tiny blast radius — one file — and is completely one-way. Both are worth asking.

The ten-second checklist

Most prompts are obvious in both directions. The interesting ones are in the middle: a command you don’t recognise, an edit touching more than you expected, something that sounds fine but you can’t quite tell. For those, four questions in order:

1. What is this actually going to do? The specific command, the specific path.
2. What’s the blast radius? Which rung of the ladder?
3. Is it a one-way door? Can you get it back?
4. Do I have my safety net? For file changes: is git up to date? Did you commit before letting Claude loose? A safety net doesn’t make you reckless — it makes the first three questions less stressful to answer.

And a fifth, for the ones that look fine but you can’t work out why Claude wants to do that particular thing:

Ask Claude to explain what it’s about to do and why — before you approve.

You can literally type “wait — what’s that command for?” Two things happen, and both are wins: either the explanation makes sense and you approve with more confidence, or the explanation reveals Claude is about to do the wrong thing for a reasonable-sounding reason, and you’ve just saved yourself a mess. This is the most underused habit in Claude Code, and it costs one sentence.

The point isn’t vigilance

None of this is an argument for reading every prompt with your full attention. That’s unsustainable, and unsustainable caution decays into no caution at all — which is worse than never having tried, because it feels like safety.

The goal is that the checklist collapses into an instinct. After a week or two you glance at a prompt, the answer is already obvious, and the only ones that slow you down are the ones that should. Not “be paranoid about every prompt”, not “trust it and click through” — just notice the ones that matter and let the rest fall through.

Two neighbouring pages finish the picture. Which prompts you see at all is a settings question: permissions and staying in control. And approving an action is not the same as understanding what it did — the accept-or-reject moment for an edit, and getting a change back after the fact, is seeing and undoing what Claude changed.