Permissions, plan mode, and staying in control

This is usually the first question anyone asks, and it deserves a direct answer: no, Claude does not quietly rearrange your files. By default it stops and asks — an approve-or-decline prompt right in the chat — before it changes anything or runs a command. The setting the docs recommend for new users is called Ask permissions, and it does exactly what the name says, every time, until you decide otherwise.

Most of the confusion in this area dissolves once you notice there are two separate dials, not one. The first is how often Claude stops to ask. The second is whether Claude proposes an approach before doing any work at all. They sound like the same question and they aren’t, which is why the comparison guide below exists.

The asking dial

Five modes exist; three of them cover almost every normal day, and you switch between them in the app’s mode selector — no settings file, nothing to memorise.

• Ask permissions — the cautious end. Everything that changes the world waits for a click. The right mode for unfamiliar work, a project you don’t know, and anything you’d be sorry to redo.
• Auto mode — the honest middle. A classifier lets the safe, boring things through (reads, tests, status checks) and still stops on anything that could do real damage, so a long task flows without you babysitting each step. It has account and model requirements, so it isn’t always offered.
• Accept edits — the middle ground people forget exists. Claude edits files freely but still asks before running commands or reaching the network. It suits a long, edit-heavy stretch where your real safety net is being able to roll the files back, and it’s a much better answer than a fast mode when the noise you’re trying to escape is specifically edit prompts.
• Plan mode — the other dial, covered below.
• Bypass permissions — every approval skipped, no safety check at all. This is a Power-Track flag for throwaway sandboxes and locked-down headless automation, and its alarming name is not decorative.

The rule that keeps you out of trouble is short: pick the slowest mode you can tolerate, not the fastest you can get away with. The slower mode catches more mistakes; the faster one trades that catch rate for momentum, and most of the time the catch rate is worth more. New project, shared code, anything with money attached → Ask permissions. A long stretch of routine work you trust → Auto. The instinct throughout is tighten before you loosen: start cautious and let individual actions earn the right to run on their own. Because permissions are scoped per project, a repository you barely trust can stay strict while a sandbox runs wide open.

Allowlist the boring stuff instead of loosening the mode

There’s a failure that looks like efficiency and isn’t. After a few sessions you’ve approved “list the files” forty times and “show me the changes” thirty, and you’ve stopped reading them. The danger isn’t the wasted seconds — it’s that once you stop reading the boring prompts, you stop reading the important ones too.

The fix is not a faster mode, because a faster mode drops all the asking at once — the frightening actions along with the dull ones. The fix is an allowlist: the specific, boring actions Claude may take without asking again, with everything else still stopping at the prompt.

You build it one click at a time. Every time you choose Always allow on a genuinely harmless action, that’s the allowlist growing; it’s nothing more than the running record of your “always” decisions.

A good allowlist makes the prompts you do see impossible to ignore.

The litmus test for adding something: would I have done this myself, without thinking? If yes, Always allow. If you’d hesitate even briefly, approve once and leave it off. Good candidates are read-only and constant — listing files, showing contents, searching, showing what changed, checking a status. Bad candidates stay on the prompt every time: anything that deletes, moves or overwrites something that matters; anything that runs your code against real systems or real data; anything that reaches the network; and anything you only learned about yesterday. Grow the list slowly, one action at a time, after you’ve seen it enough to know it’s safe everywhere you’d let it happen.

Where the allowlist actually lives

It’s worth knowing the list is a real file, because that’s what makes it shareable rather than personal folklore. The allowlist lives in settings.json, and every “Always allow” you’ve clicked has been quietly writing a line into it. It isn’t a config you author from scratch — it’s a record of decisions you already made, which you can now read and edit directly:

{
  "permissions": {
    "allow": ["Bash(git status:*)", "Bash(git diff:*)", "Bash(npm test:*)"],
    "deny": ["Bash(git push:*)"]
  }
}

allow runs without asking. deny never runs and doesn’t even ask. Anything on neither list goes through the normal prompt. You don’t need the Bash(...) syntax memorised — clicking Always allow writes it correctly, and you can also just say “add git status to my allowlist” in the chat.

There are three files, and the same project-vs-personal split you’ll see everywhere else in Claude Code:

• .claude/settings.json — in the repository, shared with the team. Rules everyone should have.
• ~/.claude/settings.json — your home folder, applies to every project, just you.
• .claude/settings.local.json — inside the project but private to you (git ignores it).

By default, Always allow writes to your local file, so your personal conveniences don’t get forced onto teammates. Promote a rule into the committed .claude/settings.json deliberately, once you’ve decided the whole team should have it. (On the Power Track, the CLI reads the same files, so what you set up on Desktop carries over — it can also take an allowlist as a launch flag, but the durable rules live in these files either way.)

Editing by hand is faster than clicking, which makes it easier to get reckless. The rule above doesn’t change: only allowlist something you’d have run yourself without a second thought. The file makes the list visible; it doesn’t change what belongs on it.

Plan mode

Plan mode is the other dial, and it is the one people underuse. In plan mode Claude is read-only: it studies the problem, writes out a numbered plan, and stops. Nothing has happened yet — you are approving the approach, not the result, and a plan you can read in ten seconds is the cheapest possible place to catch a wrong turn. Read it like a skeptic and argue with it; that is what it’s for. The two dials combine well: plan first so the strategy is right, then let auto mode carry the safe steps of that plan without interrupting you.

How to read a plan properly — and how it fits into the wider rhythm of work too big for one prompt — is tasks too big for one prompt.

Trusting a folder is a bigger decision than any single prompt

Open a folder Claude hasn’t seen before and you get a different dialog: do you trust the files in this folder? It’s asking you to vouch for the whole project rather than approve one action, and it’s easy to click through without thinking.

The reason it’s worth a beat is that a project isn’t only data Claude reads:

A project is also instructions Claude follows — a CLAUDE.md, a .claude/ folder of commands and settings, project-level skills that load automatically.

Those exist for good reasons; they’re how a team writes down “here’s how we work here” so Claude is useful from minute one. But the same mechanism means a folder from a stranger can carry instructions written for Claude rather than for you. Hostile or unexpected instructions hiding inside content Claude reads is called prompt injection, and the trust dialog is the gate in front of it.

Be deliberate rather than paranoid. Your own projects: trust freely. Your team’s: trust, but glance once at CLAUDE.md and .claude/ the first time you open it. A stranger’s folder from the internet: read those files before you trust it. Something you’re investigating precisely because it looks off: don’t trust it at all — look without handing over the keys. And the same instinct applies to content inside a trusted project: a README pulled from a sketchy link, a document downloaded from somewhere, a note from outside your team. Text Claude reads can change what Claude does.

Two boundaries this page doesn’t cover

Which prompts you see is a settings question. Whether to say yes to the one in front of you is judgment, and it has its own page: deciding what to approve — blast radius, one-way doors, and the ten-second checklist.

And approving an action is not the same as understanding what it did. The accept-or-reject moment for a file edit, and getting a change back afterwards, lives in seeing and undoing what Claude changed. Every permission you grant is a genuine grant of reach, which is where company data and privacy stops being an abstract concern.