Tired of Claude Asking Permission? Here's How to Fix It

If you use Claude Code every day, you've probably been here: you ask for a straightforward refactor, and before anything gets done you get another prompt — can I do this? 🤔

It's not the model being overly polite. It's the permission system doing its job: by default, Claude asks before it reads, writes, edits, or runs anything outside what you've already allowed.

The trouble starts when that becomes noise. You're in your project, in your folder, and the flow still breaks every thirty seconds. Productivity drops. So does patience.

Good news: you don't have to live with it. You can configure permissions once and let Claude work inside boundaries you define.

The fix: project-level permissions

At the root of your project (or the folder you usually open in Claude), create:

.claude/settings.json

That file lists what the assistant may do without asking again. Scope is path-based — you allow only what matters for that workspace, not your entire machine.

A practical example

Say you keep all your code under ~/Developer/workspaces/. A lean settings.json might look like this:

{
  "permissions": {
    "allow": [
      "Read(~/Developer/workspaces/**)",
      "Write(~/Developer/workspaces/**)",
      "Edit(~/Developer/workspaces/**)",
      "MultiEdit(~/Developer/workspaces/**)",
      "Glob(~/Developer/workspaces/**)",
      "Grep(~/Developer/workspaces/**)",
      "LS(~/Developer/workspaces/**)",

      "Bash(*)",

      "WebFetch(*)",
      "WebSearch"
    ],
    "deny": [
      "Read(~/Developer/workspaces/**/.env)",
      "Read(~/Developer/workspaces/**/.env.*)",
      "Read(~/Developer/workspaces/**/secrets/**)",
      "Read(~/Developer/workspaces/**/*.pem)",
      "Read(~/Developer/workspaces/**/*.key)",
      "Bash(rm -rf *)",
      "Bash(sudo rm *)"
    ]
  }
}

If you want a tighter setup

For most people, the config above is the fastest way to stop constant approval prompts. But if you prefer a stricter setup, you can keep the same structure and narrow specific permissions.

For example, instead of allowing any URL with WebFetch(*), you can allow only specific domains:

{
  "permissions": {
    "allow": [
      "WebFetch(https://github.com/**)",
      "WebFetch(https://docs.anthropic.com/**)",
      "WebFetch(https://stackoverflow.com/**)"
    ]
  }
}

You can also use deny to block sensitive files and dangerous commands:

{
  "permissions": {
    "allow": [
      
    ],
    "deny": [
      "Read(~/Developer/workspaces/**/.env)",
      "Read(~/Developer/workspaces/**/.env.*)",
      "Read(~/Developer/workspaces/**/secrets/**)",
      "Bash(rm -rf *)",
      "Bash(sudo rm *)"
    ]
  }
}

This pattern is useful when you still want speed for regular work, but also want explicit guardrails around secrets and destructive operations.

⚠️ Replace ~/Developer/workspaces/** with the actual path you use. The ** glob includes subfolders. Narrower paths mean tighter security.

What each permission does

Each allow entry is a rule. Claude only skips the confirmation prompt when the action matches one of them.

• Read(...) — read files under the given path.
• Write(...) — create or overwrite files.
• Edit(...) — edit existing files (targeted changes).
• MultiEdit(...) — several edits in the same file in one go.
• LS(...) — list directories and explore the tree.
• Glob(...) — find files by pattern (e.g. **/*.py).
• Grep(...) — search for text inside project files.
• Bash(...) — run shell commands. Bash(*) allows any command; for tighter control, restrict (e.g. Bash(git *) or Bash(npm *) only).
• WebFetch(...) — fetch a specific URL (docs, APIs, etc.). WebFetch(*) allows any URL — use with care.
• WebSearch — search the web when the model needs up-to-date information.

In practice, Read, Grep, Glob, and LS are the minimum for Claude to understand the repo without interrupting you. Edit, MultiEdit, and Write are what unlock real coding flow. Bash matters when you want tests, builds, git, and similar tasks without a approval queue.

Scoping safely

A few habits that work well:

• Prefer specific paths over ~/**. Your home folder, your work tree — done.
• Sensitive projects (clients, production, secrets) deserve a stricter file or no loose Bash(*).
• Reuse the pattern across repos where you spend hours. You can commit settings.json to git (no private data) so the whole team gets the same flow.
• If something still asks for permission, read the prompt — often the action is outside the glob you set. Add the right rule and move on.

Before and after

Before: “May I edit this file?” → click. “May I run npm test?” → click. “May I read the README?” → click again. Focus evaporates.

After: Claude works inside the contract in settings.json. You watch what matters; the rest flows.

Wrapping up

Claude doesn't have to be an assistant that asks about everything — it can be a partner that respects clear limits you designed. A well-tuned .claude/settings.json brings your session rhythm back and keeps you on the problem, not on a queue of clicks.

Try it on a real project, tune the paths, tighten Bash if you need to. It takes a few minutes to feel the difference — and you probably won't want to go back. 🚀