What Are the Best allowedTools Configurations for Secure Claude Workflows?

The best allowedTools configuration for Claude Code is a layered deny-ask-allow ruleset committed to a shared .claude/settings.json, with default or acceptEdits as the permission mode, secrets explicitly denied, destructive commands routed through ask, and CI pipelines locked to dontAsk. The goal is not to eliminate autonomy — it is to give Claude Code exactly the permissions it needs to be productive and nothing more, so that when something goes wrong, the blast radius is a single file, not your production infrastructure.

Claude Code runs with the same filesystem and shell permissions as the developer who invokes it. It can read any file your user can read, execute arbitrary bash commands, modify multiple files simultaneously, and reach external services through the Model Context Protocol. That power is what makes it productive. It is also what makes an unconfigured deployment a serious security exposure. The allowedTools system — the allow, deny, and ask arrays inside the permissions block of settings.json — is the primary mechanism for controlling that exposure.

Why Permission Configuration Matters in 2026

The threat model for AI coding agents shifted in 2026. It is no longer just "bad generated code" — it is arbitrary code execution by an agent that operates in your terminal with your credentials.

The data tells the story:

• 87% of AI agent pull requests contained vulnerabilities, according to a March 2026 report by DryRun Security
• Opsera's "AI Coding Impact 2026 Benchmark," tracking 250,000+ developers, found a 15 to 18% increase in security vulnerabilities when AI coding agents were introduced
• Only 10% of AI-generated code is both functional and secure, per a joint March 2026 study by Endor Labs, Carnegie Mellon University, Columbia, and Johns Hopkins
• AI coding agent security incidents are now weekly occurrences, as reported by Thoughtworks at QCon in March 2026
• Check Point Research disclosed CVE-2025-59536 (CVSS 8.7) in early 2026 — a remote code execution vulnerability in Claude Code triggered by malicious project configuration files before any trust dialog appears

The compounding factor is approval fatigue. Anthropic reported in June 2026 that users approve 93% of all permission prompts. When nearly every prompt gets a reflexive "yes," the prompt itself is not a security control — it is a ceremony. Nearly half of active Claude CLI users (49.5%) manually created a broad Bash allow-rule to suppress prompts, 43% allowed broad interpreter access like Bash(python:*), and 5% gave Claude outright blanket shell access with Bash(*). The permissions system exists to make the right choice the easy one, so you are not relying on willpower at 2 AM.

The Settings Hierarchy: Four Scopes That Merge

Claude Code reads settings from multiple settings.json files and merges permission rules additively across them. The scopes, from highest authority to lowest:

• Managed settings — enterprise policy delivered from the claude.ai console. Highest priority, the right place for organization-wide guardrails that individual developers cannot override.
• User settings (~/.claude/settings.json) — personal defaults applied across every project on your machine. Good for commit conventions and preferred tooling.
• Shared project settings (.claude/settings.json) — committed to git, shared with the entire team. This is where baseline safety rails live.
• Local project settings (.claude/settings.local.json) — git-ignored personal overrides for workflow quirks you do not want to push.

The critical rule: a deny rule defined at any scope stays in force and cannot be loosened by a less authoritative scope. If enterprise managed settings deny Read(*.env*), no project-level allow rule can unblock it. This merge behavior means you can layer organizational policy, team conventions, and personal preferences without worrying that a junior developer's local settings file accidentally removes a security guardrail.

The Three Rule Types: Deny, Ask, Allow

Inside the permissions object, three arrays control every tool call Claude Code makes:

• deny — evaluated first. If a tool call matches a deny rule, it is blocked outright with no prompt. A bare tool name like Bash removes the tool from Claude's context entirely, so Claude never even sees it. A scoped rule like Bash(rm -rf *) leaves the tool available but blocks matching calls. Deny rules survive even bypassPermissions mode, which is why they are the backbone of any secure configuration.
• ask — evaluated second. If matched, Claude pauses and forces a manual approval prompt. Use this for operations that are sometimes legitimate but dangerous enough to warrant a checkpoint — git push, npm install, creating new files with Write.
• allow — evaluated third. If matched, the tool call is auto-approved without interruption. This is where you put the commands Claude needs to run repeatedly during normal development — npm test, npm run lint, git status, git diff.

The evaluation order matters: deny wins over allow. If you have allow: ["Bash"] but also deny: ["Bash(rm:*)"], the rm command is blocked. This precedence is the mechanism that lets you grant broad access while still carving out exceptions for dangerous operations.

Pattern Syntax for Scoped Rules

Scoped rules use glob-style matching inside parentheses. Bash(npm test) matches that exact command. Bash(npm run *) matches any npm-run invocation. Read(src/**) matches any file under src/. Edit(src/**) scopes edits to a specific directory. The specificity is what makes the system practical — you can grant Claude autonomy within src/ while requiring approval for anything in infrastructure/ or migrations/.

The Six Permission Modes

Claude Code supports six permission modes that set the default autonomy level for the session. Choose based on the sensitivity of the environment:

• default — asks before any tool that could modify the system or hit the network. Reads are free. This is the safe starting point and what every new install gives you. You will see a lot of approval prompts until you build up an allow list.
• acceptEdits — auto-approves file reads, standard edits, and common non-destructive filesystem commands like mkdir, touch, cp, and mv. A good middle ground for daily development once you trust your deny rules.
• plan — read-only exploration. Claude can read the codebase and run read-only shell commands to gather context, but is blocked from making any edits until you approve a formal plan. Use this when working in unfamiliar or regulated repositories.
• auto — the default on Pro, Max, and Team plans as of August 2026. Auto-approves most tool calls but routes them through a background AI safety classifier that intercepts risky commands. A reasonable default for experienced teams with good deny rules.
• bypassPermissions — skips nearly all prompts, activated via --dangerously-skip-permissions. Still enforces prompts for protected paths like .git/ and .claude/ and respects explicit deny rules. Only for isolated VMs or Docker containers where the blast radius is zero.
• dontAsk — auto-denies all tool calls unless they explicitly match an allow rule. The correct mode for unattended CI/CD pipelines, where a hung prompt waiting for human input is a pipeline failure.

A Production-Grade Configuration

Here is a battle-tested .claude/settings.json for a team working on a TypeScript project, balancing productivity with security:

• defaultMode: "acceptEdits" — auto-approve edits but prompt for network and destructive operations
• Allow: Bash(npm test), Bash(npm run lint), Bash(npm run typecheck), Bash(git status), Bash(git diff:*), Bash(git log:*), Read(src/**), Read(docs/**), Edit(src/**)
• Deny: Read(*.env*), Read(*.pem), Read(*.key), Read(./secrets/**), Read(~/.ssh/**), Read(~/.aws/**), Bash(rm -rf *), Bash(npm publish), Bash(curl *), Bash(wget *), Bash(sudo:*), Bash(git push --force*), Bash(git reset --hard*)
• Ask: Bash(git push:*), Bash(npm install:*), Bash(docker:*), Bash(kubectl:*), Bash(terraform:*), Write(*)

The logic: reads and edits within src/ are free, so Claude can work without interruption. Destructive shell commands and secret file access are denied outright, so they are impossible regardless of context. Infrastructure and deployment commands require explicit approval, so no accidental git push --force to main. New file creation (Write) goes through ask because creating new files is higher-risk than editing existing ones — a new file can introduce an entirely new attack surface that no reviewer is expecting.

Best Practices for Enterprise Teams

Commit shared guardrails to git. Store baseline deny and ask rules in .claude/settings.json and check it in. Every teammate inherits the safety rails automatically, while still being able to add personal overrides in their git-ignored .local.json.

Fail closed in CI. Run Claude Code with --permission-mode dontAsk in CI pipelines so unapproved actions are rejected automatically rather than hanging the pipeline waiting for input that will never come.

Deny secrets by default. Explicitly list .env, .pem, .key, .ssh/, .aws/, and any other credential paths under deny. A prompt injection that tries to read your AWS credentials should fail before it starts, not trigger a prompt you might approve reflexively.

Use plan mode for unfamiliar codebases. When a new hire or contractor joins, start them in plan mode so Claude explores the architecture without the ability to make changes until the plan is reviewed. This prevents an agent from "helpfully" refactoring code it does not yet understand.

Audit quarterly. Read your settings.json cold, the way a new teammate would. Ask whether each entry still earns its slot, whether the deny list still catches what you would not want the model to do, and whether anything is a leftover from a project you are no longer running. Permissions are not set-and-forget — they are how you tell Claude what is normal, and normal changes as the codebase does.

Lock down MCP servers. MCP servers run with your full local permissions. Treat mcp add like installing a CLI tool — only add servers from sources you trust, and read the config they write before running anything sensitive. For sensitive environments, use allowManagedMcpServersOnly to restrict MCP servers to a managed catalog that is easier to audit than ad hoc project-scoped tool servers.

The Bottom Line

The difference between a secure Claude Code deployment and a dangerous one is not the model — it is the configuration. A well-tuned allowedTools setup turns a disruptive approval loop into a smooth workflow where Claude can work autonomously within safe boundaries, destructive commands are impossible, and secrets are invisible. The investment is thirty minutes of configuration that compounds across every future session. The alternative is hoping that a 93% approval rate on prompts will catch the one command that matters.

If you want help auditing your Claude Code permissions, setting up enterprise-managed settings, or configuring a secure CI pipeline with dontAsk mode, ishchuk.eu offers AI automation consulting for engineering teams. We can ship a production-ready permission configuration in days, not months.