claudecodeguide.dev

Foundations

Permissions: Stop Clicking 'Allow' on Everything

Permission fatigue is the number two complaint about Claude Code. Five minutes of config fixes it permanently. Here's exactly what to set and why.

On this page (6 sections)

Five clicks before anything actually happens.

That's what default Claude Code feels like. You ask it to fix a test. It wants to read the file. Allow. Edit the file. Allow. Run the test. Allow. Check the output. Allow. It's like having an assistant who asks permission before touching anything in the office.

The fix takes five minutes. You configure it once. Then it just works.

Before and after permission configuration

Setting Up allowedTools

The config lives in settings.json. Two places to put it:

Project-level (.claude/settings.json in your repo): gets checked into git, shared with your team. Good for project-specific tools like your test runner or lint commands.

User-level (~/.claude/settings.json): your personal defaults across every project you work on.

Here's a solid starting config:

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "LS",
      "Bash(npm test*)",
      "Bash(npm run lint*)",
      "Bash(npx tsc*)",
      "Bash(git status*)",
      "Bash(git diff*)",
      "Bash(git log*)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)"
    ]
  }
}

Read operations are always safe. Your test and lint commands are safe. Anything that deletes files or pushes to remote: always keep human review on those.

The /permissions Command

Mid-session and tired of clicking? Type /permissions to manage it on the fly.

Managing permissions mid-session

What to Auto-Accept vs What to Always Review

Always auto-accept:

  • Read: reading files literally never changes anything
  • Glob: searching file names, harmless
  • Grep: searching file contents, harmless
  • LS: listing directories, harmless
  • Bash(git status*), Bash(git diff*), Bash(git log*): read-only git commands

Auto-accept with patterns (mostly safe):

  • Bash(npm test*): running your tests
  • Bash(npm run lint*): running linters
  • Bash(npx tsc*): type checking
  • Edit: once you've used Claude Code for a week and trust the edit quality, most people add this

Always review:

  • Bash(rm *): file deletion
  • Bash(git push*): pushing to remote
  • Bash(git checkout*): branch switching
  • Bash(git reset*): resetting changes
  • Bash(npm publish*): publishing packages
  • Bash(curl*): making network requests
  • Anything touching production

The Progressive Trust Approach

Don't try to configure everything perfectly on day one. You don't yet know what Claude Code actually does in your workflow.

Week 1: Auto-accept reads only. Watch what it actually does before each operation.

Week 2: Add test and lint commands to auto-accept. You've seen enough by now to know it's not running weird shell commands.

Week 3: Add Edit if you're confident in the edit quality. Most people get here.

Week 4+: You're reviewing only destructive operations and network calls. That's the sweet spot: 90% of operations flow without interruption, 10% get a human eye where it matters.

The permission sweet spot

One More Thing: The Accept Button

When a permission prompt does appear, you've got more options than just Y:

  • y: Allow this once
  • a: Allow this tool for the entire session (use this during exploratory work)
  • n: Deny this request
  • Escape: Cancel the current operation

The a option is underused. When you're in an exploratory session and trust the general direction but didn't pre-configure permissions, a gets you out of the click loop fast.

New guides, when they ship

One email, roughly weekly. CLAUDE.md templates, workflows I actually use, and the cut-for-length stuff that does not make the public guides. One-click unsubscribe.

Or follow on Substack