How to Stop Claude Code From Asking Permission Every Time

If you use Claude Code regularly, you already know the drill. Every time you run a command, edit a file, or search the web, it asks for your permission first. For quick tasks that is fine. But when you are deep in a coding session and the permission prompts keep interrupting your flow, it gets old fast.

The good news is there is a simple way to fix this. You can configure Claude Code to automatically allow specific tools while still blocking dangerous operations. Here is exactly how to set it up.

Why Claude Code Asks for Permission

Claude Code is designed to be cautious by default. It asks permission before running shell commands, reading files, editing code, or accessing external services. This is a safety feature that prevents the AI from accidentally deleting files, exposing sensitive data, or running destructive commands without your knowledge.

The problem is that most of the time you are running perfectly safe operations. Reading a source file, running a test suite, or searching for a function definition should not require a confirmation click every single time. That is where code assistant configuration comes in.

The Fix Using settings.local.json

The recommended solution is to create a local settings file inside your project directory. Claude Code looks for a .claude folder in your current working directory, and inside that folder, it checks for a file called settings.local.json. This file lets you define which tools are allowed and which are denied without affecting other projects.

Here is the file path you need to create.

your-project-folder/.claude/settings.local.json

And here is the content you should put inside it.

{
  "permissions": {
    "allow": [
      "Bash",
      "Read",
      "Edit",
      "WebSearch",
      "WebFetch",
      "mcp__claude-in-chrome__*"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Read(.env)",
      "Read(**/.env)"
    ]
  }
}

Once you save this file, Claude Code will stop asking for permission on the tools listed in the allow array. It will silently approve Bash commands, file reads, edits, web searches, and browser operations while still blocking the dangerous ones you defined in the deny array.

What Each Permission Does

Let us break down what each entry in the allow and deny lists actually controls.

The wildcard pattern mcp__claude-in-chrome__* is especially useful. It allows all Chrome-related automation tools at once instead of listing each one individually.

How to Create the Settings File

If your project does not already have a .claude folder, you need to create one. Here are the steps.

• Open your terminal and navigate to your project root directory.
• Create the hidden folder with mkdir -p .claude if it does not already exist.
• Create the settings file with your preferred text editor at .claude/settings.local.json.
• Paste the JSON configuration shown above and save the file.
• Restart Claude Code or start a new session for the changes to take effect.

You can also do this entirely from the command line.

mkdir -p .claude
cat > .claude/settings.local.json << 'EOF'
{
  "permissions": {
    "allow": [
      "Bash",
      "Read",
      "Edit",
      "WebSearch",
      "WebFetch",
      "mcp__claude-in-chrome__*"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Read(.env)",
      "Read(**/.env)"
    ]
  }
}
EOF

Why the Deny List Matters

You might be tempted to allow everything and skip the deny list entirely. That is a bad idea. The deny rules act as guardrails that protect you even when broad permissions are granted.

Blocking rm -rf * prevents Claude Code from accidentally wiping your entire directory. This is the kind of security measure you never want to skip. Blocking .env file reads ensures your API keys, database passwords, and other secrets stay hidden from the AI context.

Think of the deny list as your safety net. The allow list makes Claude Code faster. The deny list keeps it safe.

Local vs Global Settings

Claude Code supports two levels of settings configuration. The settings.local.json file lives inside your project and only applies to that specific project. This is the recommended approach because different projects have different security needs.

A web scraping project might need WebFetch permissions while a backend API project might not. Keeping settings local lets you customize permissions per project without creating unnecessary risk elsewhere. This is similar to how developers configure AI tools for specific codebases.

There is also a global settings file at ~/.claude/settings.json that applies across all projects. But for most developers, the project-level file is the better choice because it travels with the repository and keeps your permission rules close to the code they apply to.

Customizing Permissions for Your Workflow

The configuration shown above is a solid starting point, but you can adjust it to match your specific workflow. Here are some common additions.

• Add Write to the allow list if you want Claude Code to create new files without asking.
• Add specific MCP server tools if you use integrations like Slack, Linear, or productivity tools.
• Add more deny patterns like Bash(git push --force) to prevent dangerous git operations.
• Add Bash(docker rm *) to prevent accidental container deletion if you work with Docker.

The key is to allow the tools you use constantly and deny the specific commands that could cause real damage. You do not need to list every possible dangerous command, just the ones that are relevant to your development workflow.

Common Mistakes to Avoid

There are a few pitfalls when setting up Claude Code permissions that you should watch out for.

First, do not commit settings.local.json to your git repository if it contains project-specific preferences that other team members might not share. Add .claude/settings.local.json to your .gitignore file instead.

Second, do not forget to deny .env reads. If you allow the Read tool globally but forget to block environment files, Claude Code can accidentally include your secrets in its data analysis context.

Third, make sure your JSON syntax is valid. A missing comma or bracket will cause Claude Code to ignore the entire settings file silently. Use a JSON validator if you are unsure.

Testing Your Configuration

After creating the settings file, start a new Claude Code session in your project directory. Try running a few common operations like reading a file, running a shell command, or doing a web search. If the configuration is working correctly, these actions should execute immediately without any permission prompt.

Then test the deny rules. Ask Claude Code to read your .env file or run rm -rf *. It should refuse or ask for explicit confirmation, proving that your safety rules are active.

A well-configured settings file turns Claude Code from a cautious assistant into a fast, hands-off coding partner while keeping the guardrails that actually matter.

Conclusion

Stopping Claude Code from asking permission every time comes down to one file. Create .claude/settings.local.json in your project root, define your allow and deny lists, and restart your session. The allow list removes the constant interruptions for safe operations. The deny list keeps dangerous commands locked behind explicit approval. This setup gives you the speed of unrestricted access with the safety of targeted restrictions, which is exactly how AI coding tools should work out of the box.