Permission Models & Security

What You’ll Learn

Claude Code security is not one switch. It combines:

1. A permission mode that sets the session baseline
2. allow, ask, and deny rules for specific tool calls
3. Protected paths and organization policy
4. Optional OS-level sandboxing for Bash and child processes
5. Hooks for deterministic checks around tool execution

This session focuses on choosing controls deliberately, especially the difference between Auto mode and bypassing permissions.

The Permission Modes

UI label	Configuration value	Without routine approval	Best fit
Manual	default (manual alias)	Reads	Sensitive or unfamiliar work
Edit automatically	acceptEdits	Reads, file edits, common filesystem commands	Reviewed local iteration
Plan	plan	Reads and read-only exploration	Design before implementation
Auto	auto	Actions that pass background safety checks	Trusted direction, fewer interruptions
Don’t ask	dontAsk	Pre-approved and built-in read-only actions	Locked-down CI and scripts
Bypass permissions	bypassPermissions	Almost everything	Isolated containers and VMs only

Manual / default

Manual is the current UI label; default remains the configuration value used by settings, hooks, and SDK integrations. The CLI also accepts manual as an alias in v2.1.200 or later.

Inside the working directory, reads normally proceed without asking. File edits and non-read-only Bash commands normally prompt. This is the safest general-purpose starting point because the user reviews side effects as they arise.

claude --permission-mode default
# v2.1.200+
claude --permission-mode manual

Plan / plan

Plan mode is for read-only investigation and design. Claude can read files and use built-in read-only shell commands, but it does not edit source files. Non-read-only shell commands prompt even while planning.

claude --permission-mode plan

Plan mode does not mean “approve every read.” It creates a checkpoint before implementation: review the proposed plan, keep refining it, or approve it and choose the mode used for execution.

Auto / auto

Auto mode removes routine permission prompts but keeps background safety checks. A separate classifier evaluates actions that are not already resolved by explicit rules or safe local behavior. Explicit deny and ask rules still apply, and the classifier can block actions that exceed the request, target unfamiliar infrastructure, or appear driven by hostile content.

claude --permission-mode auto

Auto mode reduces prompt fatigue; it is not a guarantee of safety and not a replacement for review on sensitive operations. Availability depends on account, model, provider, and organization settings.

Don’t ask / dontAsk

dontAsk never waits for permission input. Calls that would normally prompt are denied. It runs only pre-approved actions, built-in read-only Bash commands, and calls approved by an applicable hook.

claude --permission-mode dontAsk

Use it for CI or scripts where waiting for a human would deadlock the run and the allowed surface is defined in advance.

Bypass permissions / bypassPermissions

Bypass mode skips ordinary permission prompts and safety checks. Use it only inside an isolated container or VM that has no valuable credentials and cannot damage the host or production systems.

claude --permission-mode bypassPermissions
# Equivalent legacy flag:
claude --dangerously-skip-permissions

The dangerous flag is not Auto mode. A few circuit breakers and externally required consent prompts can still fire, but bypass mode provides no general protection against prompt injection or unintended actions.

Rules: Deny, Then Ask, Then Allow

Put rules under permissions.allow, permissions.ask, and permissions.deny:

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm test *)",
      "Read(/docs/**)",
      "WebFetch(domain:docs.example.com)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(~/.ssh/**)",
      "WebFetch(domain:paste.example)"
    ]
  }
}

Rules use Tool or Tool(specifier) syntax and are evaluated deny → ask → allow. Specificity does not override that order. If Bash(aws *) is denied, a narrower allow for Bash(aws s3 ls) cannot punch through it.

Use /permissions to inspect and edit effective rules. Keep allow patterns narrow: Bash(npm test *) is easier to reason about than blanket Bash access.

Permissions and Sandboxing Are Different

Permissions govern whether Claude Code may invoke a tool. Sandboxing, when enabled, enforces operating-system filesystem and network boundaries on Bash commands and their child processes.

Model proposes Bash command
        ↓
Permission mode + rules + hooks
        ↓ allowed
Optional OS sandbox boundary
        ↓
Operating system executes or blocks the effect

Sandboxing is not automatically synonymous with any permission mode. Configure it separately, and do not assume a permission rule alone stops an arbitrary Python or Node subprocess from reading a file. Use both layers when the threat model includes untrusted code or prompt injection.

Explicit deny rules still apply when sandboxing auto-allows a command. Protected paths also receive special treatment in every mode except bypass, where most protected-path checks are skipped.

Hooks and Organization Policy

A PreToolUse hook can inspect a pending action and block it before execution. Hooks are useful for deterministic requirements such as rejecting production targets or enforcing an approved command wrapper. They complement permission rules; they do not override a matching deny or ask rule.

Organizations can ship managed settings that users and projects cannot override. Because deny rules from any settings scope win, a project allow rule cannot override an organization-level deny.

Choosing a Mode

Need to understand before editing?       → plan
Want to review each side effect?         → default / Manual
Trust local edits, review commands?      → acceptEdits
Want fewer prompts with safety checks?   → auto
Need non-interactive allowlisted CI?     → dontAsk
Fully isolated disposable environment?   → bypassPermissions

For durable human checkpoints, encode an ask or deny rule. A conversational instruction such as “do not push” helps Auto mode’s classifier, but it can be lost after context compaction; a permission rule is the stronger boundary.

Security Checklist

• Start with the least permissive mode that still lets the workflow progress.
• Keep secrets and production credentials out of autonomous environments.
• Use narrow allow patterns and explicit ask rules for publication or deployment.
• Add deny rules for paths and commands that must never be touched.
• Enable sandboxing when executing untrusted code.
• Treat MCP servers, fetched content, and repository instructions as potential prompt-injection sources.
• Verify effects—tests, diffs, deployment state—not merely Claude’s claim that a task completed.

Official sources

• Choose a permission mode
• Configure permissions
• Sandboxing
• Hooks reference

Last verified: 2026-07-20.