Stop Claude from asking

Back in Level 5 you learned why to allowlist the boring commands: when Claude stops asking about git status for the fortieth time, the prompts you do see become impossible to ignore. We promised you’d see where that list actually lives. This is where.

The allowlist lives in a file called settings.json, and every time you choose “Allow always” on a permission ask, you’re quietly writing a line into it.

You’ve been writing it already

Here’s the thing most people don’t realize: when a permission ask pops up in the chat and you click “Allow always” instead of just “Allow once,” Claude writes that rule into settings.json for you. You’ve probably been building an allowlist for a while without ever opening a file.

So settings.json isn’t some scary config you have to author from scratch. It’s a record of decisions you’ve already made — and now you can read it and edit it directly.

What it looks like

Open it in the Desktop file pane and the permissions section reads almost like English:

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

allow is the green list — run these without asking. deny is the red list — never run these, don’t even ask. Anything not on either list still goes through the normal ask-me-first flow. You can edit these by hand: add a line to allow and the ask for that command stops; add one to deny and Claude won’t touch it.

(Don’t worry about getting the Bash(...) syntax perfect from memory — clicking “Allow always” writes it correctly for you, and you can copy the pattern. You can also just ask Claude in the chat: “add git status to my allowlist.”)

Where the “Ask permissions” setting lives

You met “Ask permissions” mode back in Level 5 — the recommended setting that has Claude check in before anything risky. That choice, and how often Claude pauses to ask, is a setting too. You can flip it from the Desktop settings menu without editing any file, or run /config in the chat to open the same controls. The allowlist and the permission mode are two halves of the same dial: the mode decides how cautious Claude is, and the allowlist carves out the specific boring exceptions.

Three files, same idea you’ve seen all level

settings.json follows the exact same project-vs-personal split as CLAUDE.md and commands:

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

By default, “Allow always” writes to your local file — so your personal allowlist doesn’t get forced onto teammates. If you want a rule shared, move that line into the committed .claude/settings.json on purpose (in the file pane, or just ask Claude to do it).

The safe default: let “Allow always” build your private local list. Promote a rule to the shared file only when you’ve decided the whole team should have it.

The discipline still applies

Editing the file by hand is faster than clicking, which makes it easier to get reckless. The Level 5 rule hasn’t changed: only allowlist a command if you’d have run it yourself without a second thought, and grow the list slowly. The file just makes the list visible — it doesn’t change what belongs on it.

On the Power Track: the terminal version of Claude Code reads the same settings.json files. There you can also pass an allowlist on the command line when you launch (the --allowedTools flag), but the durable rules live in exactly these files — so everything you set up on Desktop carries over, and vice versa.

What’s next

You’ve now met every knob: CLAUDE.md, memory, slash commands, and settings. The last lesson pulls them together into a single twenty-minute setup — your personal Claude, configured the way you work.