Read time: ~13 minutes. Key facts:

• Since Claude Code v2.1.283, auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions on every plan and provider. A separate classifier model reviews actions instead of you.
• There are six modes: default (shown as Manual), acceptEdits, plan, auto, dontAsk and bypassPermissions. Switch with Shift+Tab or start with --permission-mode.
• Rules are checked in the order deny, then ask, then allow. Deny rules block in every mode, including bypassPermissions. Content-scoped ask rules such as Bash(git push *) still prompt in auto mode.
• When a session enters auto mode, broad allow rules such as Bash(*), Bash(python*), package-manager run commands, and Agent and Monitor allow rules are set aside until you leave it.
• defaultMode: "auto", defaultMode: "bypassPermissions" and the whole autoMode block are not honored from a repo’s .claude/settings.json or .claude/settings.local.json. Put them in ~/.claude/settings.json.
• Admins can remove bypass mode or auto mode with permissions.disableBypassPermissionsMode or permissions.disableAutoMode set to "disable" in managed settings.

What we tested: we installed @anthropic-ai/claude-code@2.1.303 (the npm latest tag on October 19, 2026; stable was 2.1.292) on Linux, confirmed the --permission-mode choices and the permission flags in claude --help, ran claude auto-mode defaults, and ran claude doctor. We did not run a signed-in session, so nothing below is our measurement of how often the classifier blocks or allows an action. Behavior described here comes from the official Claude Code docs.

Claude Code now starts most interactive sessions in auto mode, so the question for anyone using it daily is no longer “should I approve this command?” but “what is allowed to run without me, and where are the hard limits?” This guide walks through the permission system in the order you’d set it up: check which mode you start in, choose a default per scope, write rules that match what you think they match, add human checkpoints, tell auto mode about your infrastructure, add OS-level sandboxing, configure CI, and lock things down for a team.

If you are new to Claude Code’s building blocks (CLAUDE.md, skills, subagents, MCP), start with our Claude Code daily driver guide and come back here when you want to tighten or loosen what it can do.

---

1. The six permission modes at a glance

A permission mode sets which actions Claude can take without asking you first. Rules you write sit on top of the mode. This table is from the official permission modes page:

Mode	What runs without asking	Best for
default (Manual)	Reads only	Reviewing every action, sensitive work
acceptEdits	Reads, file edits, and common filesystem commands (mkdir, touch, mv, cp, etc.)	Iterating on code you review with git diff afterwards
plan	Reads, plus classifier-approved commands when auto mode is available	Exploring a codebase before changing it
auto	Everything, with background safety checks	Long tasks, fewer prompts
dontAsk	File reads in your working directories and pre-approved tools; anything that would prompt is denied	Locked-down CI and scripts
bypassPermissions	Everything	Isolated containers and VMs only

A few details worth knowing before you pick one:

• Manual is default. The CLI, IDE extensions and desktop app label it Manual, while hooks and SDKs use the config value default. The CLI accepts manual as an alias, for example claude --permission-mode manual.
• The status bar tells you where you are. You’ll see ⏸ manual mode on, ⏵⏵ accept edits on, ⏸ plan mode on, ⏵⏵ auto mode on, ⏵⏵ don't ask on or ⏵⏵ bypass permissions on.
• Shift+Tab cycles modes in the CLI. From auto, the first press goes to Manual, then acceptEdits, then plan. dontAsk never appears in the cycle, and bypassPermissions appears only if the session was started with it enabled.
• Some actions are never auto-approved in any mode, including explicit ask rules, tools that need user interaction such as AskUserQuestion, and rm/rmdir removals that target a critical path such as /, your home directory or your working directory.

In 2.1.303, claude --help lists the accepted values for --permission-mode as acceptEdits, auto, bypassPermissions, manual, dontAsk and plan.

---

2. Step 1: Check your version and which mode you start in

Check your version first, because several behaviors in this guide depend on it:

claude --version

If you installed with npm and want the current release, npm install -g @anthropic-ai/claude-code@latest gets you the latest tag (2.1.303 when we checked). If you track the slower channel, @stable was 2.1.292.

When a new terminal session starts, Claude Code takes the permission mode from the first of these that applies:

1. The --permission-mode flag, or --dangerously-skip-permissions.
2. permissions.defaultMode in a settings file.
3. The built-in default.

The built-in default depends on how you run Claude Code. The first matching row wins:

How you run it	Built-in starting mode
Any settings file sets disableAutoMode to "disable"	default
claude -p or the Agent SDK	default in sessions that fetch feature flags; auto (v2.1.285+) in sessions that don’t, such as on a third-party provider or with telemetry off
Organization with the HIPAA configuration applied	default (v2.1.285+), with auto still available to switch to
Interactive terminal or VS Code extension	auto with v2.1.283 or later

If the flag, a settings file or the built-in default picks auto but auto mode isn’t available to that session, for example because the model doesn’t support it, the session starts in Manual instead.

Auto mode needs a supported model. On the Anthropic API and Claude Platform on AWS that means Claude Opus 4.6 or later, Sonnet 4.6 or later, Haiku 5.5, or a Fable model. On Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry and signed-in Claude apps gateway sessions, it’s Sonnet 5 or later, Opus 4.7 or later, Haiku 5.5 and the Fable models. Sonnet 4.5, Opus 4.5, Haiku 4.5 and claude-3 models aren’t supported anywhere.

For background on why the default flipped, see our news post on auto mode becoming the default.

---

3. Step 2: Set a starting mode at the right scope

You can set the starting mode for one session, one machine, one project or a whole organization:

Scope	How
One session	claude --permission-mode plan (works with -p too)
Every session on this machine	permissions.defaultMode in ~/.claude/settings.json
Every terminal session in one project	permissions.defaultMode in the project’s .claude/settings.json (all values except auto and bypassPermissions)
Every terminal session in an organization	permissions.defaultMode in managed settings

To make every terminal session on your machine start in Manual, save this in ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default"
  }
}

To start in auto mode by default, put "defaultMode": "auto" in the same user file. This is the most common mistake in this area: if you set "auto" in a repo’s .claude/settings.json or .claude/settings.local.json, it doesn’t take effect, and the session falls back to the built-in default. "bypassPermissions" in those two files also doesn’t take effect; the session starts in Manual. The point is that a cloned repository can’t switch your safety checks off for you.

A project-level plan default is fine and useful for repos where you want Claude to research before editing:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

VS Code is different. The extension never reads a project’s .claude/settings.json for the starting mode. Set claudeCode.initialPermissionMode in your VS Code user settings to default, manual, acceptEdits, plan or bypassPermissions. That setting doesn’t accept auto: to start in Auto, leave it unset and pick Auto from the mode indicator once; the extension remembers Manual, Edit automatically and Auto between conversations.

---

4. Step 3: Write allow, ask and deny rules that match what you think

Permission modes set the baseline. Rules let you pre-approve, force a prompt for, or block specific tools. You can manage them with the /permissions command, which lists every rule and the settings file it came from, or edit settings.json directly.

How rules are evaluated

• Allow rules let a tool run without approval. Ask rules always prompt. Deny rules block.
• The order is deny, then ask, then allow, and specificity doesn’t change it. A broad deny like Bash(aws *) blocks aws s3 ls even if you also allow Bash(aws s3 ls).
• A deny that names a whole tool, such as Bash, removes it from Claude’s context entirely. A scoped deny such as Bash(rm *) leaves the tool available and blocks matching calls.
• Rules are enforced by Claude Code, not by the model. Writing “never push” in CLAUDE.md shapes what Claude tries, but it doesn’t change what Claude Code allows.

Rule syntax

Rules look like Tool or Tool(specifier):

Rule	Matches
Bash	Every Bash command
Bash(npm run build)	Exactly npm run build
Bash(npm run *)	npm run build, npm run test --watch, and bare npm run, but not npm install
Read(./.env)	Reading .env in the current directory
WebFetch(domain:example.com)	Fetches to example.com
mcp__github__get_*	The get_ tools of the github MCP server (allowed as an allow rule because the server name is literal)

Three wildcard rules from the docs prevent most surprises:

1. Put the * after the subcommand. Bash(git log *) allows only git log commands; Bash(git *) allows every git command. Claude Code warns at startup about an allow rule with a * before the subcommand, such as Bash(git * main).
2. The space before a trailing * matters. Bash(ls *) doesn’t match lsof; Bash(ls*) does.
3. :* at the end is the same as *. Bash(ls:*) equals Bash(ls *), but the colon form only works at the end.

A starter project config

This is a reasonable .claude/settings.json for a Node project. It lets Claude run npm scripts and make commits, asks before pushing or opening PRs, and blocks secrets and raw curl:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npm test *)",
      "Bash(git commit *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

Project allow rules and additionalDirectories only apply after you accept the workspace trust dialog for that folder. Deny and ask rules apply immediately, because they only restrict.

What a Bash rule does not catch

Claude Code understands shell operators, so Bash(safe-cmd *) doesn’t approve safe-cmd && other-cmd, and deny/ask rules apply to any subcommand, including ones inside $(...) or a for loop. But a rule matches the command text, not the program. The docs give these examples of what a deny or ask rule does not stop:

Rule	Stops	Doesn’t stop
Bash(curl *)	curl https://example.com	/usr/bin/curl https://example.com, sh -c 'curl https://example.com'
Bash(rm *)	rm -rf build/	/bin/rm -rf build/, bash -c 'rm -rf build/'
Bash(git push *)	git push origin main	git -C . push origin main, git -c push.default=current push origin main

So treat Bash rules as guardrails for the commands Claude usually writes, not a security boundary. For a real boundary, use the sandbox in step 6 or a PreToolUse hook that inspects the full command.

File rules and paths

• Read and Edit rules use gitignore-style patterns. //path is absolute from the filesystem root, ~/path is from your home directory, /path is relative to the settings file’s location, and path or ./path is relative to the current directory. A single leading slash is not absolute.
• A Read deny also blocks Edit and Write on the same path. Use Edit(docs/**) rather than Write(docs/**); Claude Code only consults Read and Edit path rules and warns at startup about the others.
• A .claudeignore file has no effect. Move its entries into Read deny rules.
• File deny rules cover Claude’s file tools and file commands Claude Code recognizes in Bash (cat, head, tail, sed, tee, redirections). They don’t cover a Python or Node script that opens files itself. The sandbox does.

When you answer “Yes, and don’t ask again” on a prompt for a Bash command or a WebFetch domain, Claude Code saves the rule to .claude/settings.local.json at the repository root, so it applies across the repo and its worktrees.

---

5. Step 4: Keep human checkpoints while in auto mode

By default, auto mode lets Claude push to any branch of the repository you’re working in, including the default branch, and create pull requests that match your request. The push content is still checked, so force pushes or secrets entering a commit stay blocked. If you want to approve every push yourself while keeping auto mode for everything else, add ask rules. The official auto mode configuration page uses exactly this recipe:

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

Content-scoped ask rules are evaluated before the classifier and always force a prompt, even in auto mode. The same text-matching caveat applies: git -C <dir> push doesn’t match.

Pick the mechanism by how firm the boundary needs to be:

Boundary	Mechanism	Behavior in auto mode
Prompt before the action	permissions.ask	Always prompts for a matching command
Never run the action	permissions.deny	Blocked before the classifier runs; nothing overrides it
One-off, this session only	Say it, e.g. “don’t push until I review”	The classifier blocks matching actions, but the boundary can be lost if context compaction removes that message

Approvals you give in conversation have rules too. To clear a block, your message has to name the action and the specific thing that makes it risky, such as the branch of a force push. “You can force-push” on its own clears nothing, and an approval normally covers one action.

What auto mode blocks and allows by default

The default block list is long. Highlights include curl | bash, sending sensitive data to external endpoints, production deploys and migrations, mass deletion in cloud storage, granting IAM or repo permissions, force push, git reset --hard and similar commands that discard uncommitted work, terraform destroy, writing to secret managers or changing DNS, merging a PR no human approved, and launching another agent with --dangerously-skip-permissions. Allowed by default: local file operations in your working directory, installing dependencies declared in your lock files, reading .env and sending credentials to their matching API, read-only HTTP requests, and pushing to the repo you’re working in.

Also note that entering auto mode sets aside broad allow rules that grant arbitrary code execution (Bash(*), PowerShell(*), wildcarded interpreters like Bash(python*), package-manager run commands, Agent and Monitor allow rules). Narrow rules like Bash(npm test) stay in effect, and the dropped rules come back when you leave auto mode.

---

6. Step 5: Teach auto mode about your infrastructure

Out of the box, the classifier trusts only your working directory and the repo’s configured remotes. Pushing to another repo in your company’s org, or writing to a team bucket, gets blocked until you tell it about them. You do that with the autoMode block.

First, look at what ships by default:

claude auto-mode defaults

In 2.1.303 this printed a JSON object with 17 allow rules, 72 soft_deny rules, 1 hard_deny rule (Data Exfiltration) and 21 environment entries. To read one rule in full, pass a label prefix:

claude auto-mode defaults --label 'Git Destructive'

Then add your own entries to ~/.claude/settings.json. Always include "$defaults", which splices in the built-in list so you keep inheriting updates:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ]
  }
}

Leaving "$defaults" out of an array replaces that whole section. Doing that to soft_deny throws away every built-in soft block, including force push, curl | bash and production deploys. Doing it to hard_deny removes the built-in data exfiltration rule.

The other lists work the same way:

• autoMode.allow: exceptions to soft blocks, written as prose, e.g. “Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy”.
• autoMode.soft_deny: extra destructive risks that a clear user request can still clear.
• autoMode.hard_deny: boundaries that nothing clears.

Where the classifier reads autoMode from matters. It reads your user settings, managed settings, and the --settings flag or Agent SDK. It does not read autoMode from .claude/settings.json or .claude/settings.local.json, so a checked-in repo can’t add its own allow rules. Entries from different scopes are combined.

Useful commands once you’ve edited it:

Command	What it does
claude auto-mode config	Prints the effective rules: your settings where set, defaults otherwise
claude auto-mode critique	AI review of your custom rules for ambiguous, redundant or false-positive-prone entries
claude auto-mode reset	Removes the autoMode section from ~/.claude/settings.json after confirming (v2.1.212+)
/auto-mode-setup	In a session, drafts environment entries from your project and recent sessions (Pro, Max or Team plan, v2.1.228+)
/permissions, Auto mode tab	View and edit classifier rules without opening the file (v2.1.246+)

If you want every shell command reviewed, even ones your narrow allow rules cover, set "autoMode": { "classifyAllShell": true }. That trades latency for coverage: each shell command waits for a classifier decision.

Cost note. The classifier runs on Claude Sonnet 5 by default, not on your /model choice. On Enterprise plans and on Claude API, Claude Platform on AWS, Bedrock, Agent Platform and Foundry accounts, classifier calls count toward your token usage, mostly from shell commands and network operations, since reads and working-directory edits skip the classifier. When the server does the review as part of your model requests, there are no separate classifier calls. If you’re tracking spend, pair this with our guide to cutting Claude Code token overhead.

---

7. Step 6: Add the Bash sandbox for a real boundary

Permission rules decide whether Claude asks. The sandbox decides what a command can reach once it runs: it restricts Bash, PowerShell and Monitor commands and their child processes at the OS level, so it still holds if a prompt injection gets past Claude’s judgment.

Install what it needs. On macOS it uses the built-in Seatbelt framework. On Linux and WSL2 it needs bubblewrap and socat; the /sandbox panel shows a Dependencies tab if anything is missing.

Turn it on. In a session, run:

/sandbox

Pick a mode on the Mode tab:

• Auto-allow: commands that run inside the sandbox are approved without a prompt. Deny rules, content-scoped ask rules like Bash(git push *), and critical-path rm still apply.
• Regular permissions: every Bash command still goes through normal prompts, even when sandboxed.

The panel saves your choice to .claude/settings.local.json for that project. To enable it everywhere, set sandbox.enabled to true in ~/.claude/settings.json. To try a strict sandbox for one session, where Claude can’t retry a blocked command outside it:

claude --settings '{"sandbox": {"enabled": true, "allowUnsandboxedCommands": false}}'

By default, sandboxed commands can write to the working directory, a per-user temp directory, and directories added with --add-dir. If a tool such as kubectl needs to write elsewhere, grant that path rather than excluding the tool:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"]
    }
  }
}

Note that sandbox paths use normal conventions (/tmp/build is absolute), unlike Read/Edit rules where absolute paths need //.

Confirm it works. Ask Claude (don’t type it yourself at the ! prompt, which usually runs outside the sandbox) to run:

Command	Expected result in the sandbox
touch ~/sandbox-probe	Operation not permitted on macOS, Read-only file system on Linux and WSL2
curl --noproxy '*' https://example.com	Could not resolve host

If Claude asks to retry outside the sandbox, decline. One important default: if the sandbox can’t start because a dependency is missing, Claude Code runs commands without sandboxing. Set sandbox.failIfUnavailable to true if you’d rather it exit.

---

8. Step 7: Configure CI and headless runs

For pipelines, you want a session that never waits for input and only does what you listed. That’s dontAsk with an explicit allowlist, straight from the docs:

claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"

In dontAsk, anything that would prompt is denied, including calls matching your ask rules and AskUserQuestion. Critical-path removals such as rm -rf ~ are denied even if an allow rule or hook approves them.

Other headless details that bite people:

• Set the mode explicitly in scripts. Per the table in step 1, claude -p starts in default in sessions that fetch feature flags and in auto (v2.1.285+) in sessions that don’t. Passing --permission-mode removes the guesswork. Our Claude Code 2.1.302 notes cover a related starting-mode change on third-party providers.
• In -p auto mode, critical-path removals are denied immediately, because there’s no terminal to prompt in. Claude is told to report what it wanted to delete.
• Repeated blocks don’t stop a -p run. Interactive auto mode pauses and goes back to prompting after 3 blocks in a row or 20 in total; a -p run without --permission-prompt-tool just skips the blocked action and keeps working.
• Running in a repo you didn’t write? claude -p never shows the trust dialog. Use --setting-sources user so it reads neither the project’s settings nor its .mcp.json, or --bare to skip project hooks, skills, subagents, plugins and MCP servers. To turn hooks off for one run, pass --settings '{"disableAllHooks": true}'.

Fully unattended runs. --dangerously-skip-permissions (equivalent to --permission-mode bypassPermissions) is meant for containers or VMs. On Linux and macOS, Claude Code refuses to start in this mode as root or under sudo with:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

The docs point you to the dev container configuration, which runs Claude Code as a non-root user. Bypass mode offers no protection against prompt injection. Deny rules still apply in it, but allow rules have no effect. Cloud sessions ignore bypassPermissions and dontAsk from settings files.

---

9. Step 8: Lock it down for a team

Managed settings are deployed by your organization (a managed-settings.json file, an MDM policy, or server-managed settings from the claude.ai console), and user or project settings can’t override them. The permission keys most teams care about:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(./.env)",
      "Bash(terraform destroy *)"
    ]
  }
}

• permissions.disableBypassPermissionsMode: "disable" removes bypass mode. It works from any scope, so an individual can also set it in their own user settings to lock themselves out.
• permissions.disableAutoMode: "disable" removes auto from the Shift+Tab cycle, and --permission-mode auto starts in Manual instead. Since v2.1.251, a running auto session leaves auto mode when the setting arrives from an admin-deployed source.
• allowManagedPermissionRulesOnly makes managed settings the only source of permission rules.
• A managed deny can’t be overridden by --allowedTools or any other level. For anything that must never run regardless of classifier configuration, use permissions.deny in managed settings rather than autoMode.hard_deny; the docs note that autoMode entries combine across scopes and a developer’s allow entry can override an organization soft_deny.
• Distribute trusted infrastructure (your source-control org, internal domains, buckets) through autoMode.environment in managed settings so everyone gets fewer false positives.

To enforce sandboxing for everyone, the sandbox docs have a dedicated managed-settings section; combine it with sandbox.failIfUnavailable.

---

10. Troubleshooting

“Auto mode is unavailable.” Check the model requirements in step 1 and whether any settings file sets disableAutoMode. Anthropic can also turn auto mode off server-side, or the server may reject it for your account; a session that gets either answer keeps auto off until it ends, so start a new session later.

I set defaultMode: "auto" but the session starts in Manual with no error. The setting is almost certainly in .claude/settings.json or .claude/settings.local.json. Move it to ~/.claude/settings.json. In VS Code, check claudeCode.initialPermissionMode and the mode indicator instead.

“Auto mode cannot determine the safety of an action.” A classifier request failed. It’s usually transient, but on Bedrock it can repeat until your account can invoke the named model. A dim Not run · auto mode's check had no usable answer row means the same kind of thing: no verdict, not a judgment that the action is unsafe.

Something routine keeps getting Denied by auto mode classifier. The bracketed text, such as [Data Exfiltration], names the rule that matched. Open /permissions, go to Recently denied, and press r to retry with manual approval. If it’s a destination you use all the time, add it to autoMode.environment (or run /auto-mode-setup), then confirm with claude auto-mode config. Use /feedback to report false positives.

Auto mode stopped and started prompting again. That’s the fallback after 3 blocks in a row or 20 total. These thresholds aren’t configurable. Approving the prompted action resumes auto mode.

Behind an LLM gateway, checked actions are denied with no safety verdict. When ANTHROPIC_BASE_URL points at a gateway, Claude Code asks the server to review actions. If the gateway drops the review request, Claude Code falls back to its own classifier, but a proxy that cuts responses short or rewrites the review results makes Claude Code deny those actions rather than run them unreviewed. Setting CLAUDE_CODE_AUTO_MODE_SERVER=0 makes Claude Code send its own classifier requests instead.

--dangerously-skip-permissions refuses to start. You’re running as root or with sudo. Run as a non-root user inside the container.

A startup warning about a wildcard. You likely wrote an allow rule with * before the subcommand, such as Bash(git * main), which matches far more than intended. Rewrite it as Bash(git log * main) or similar.

---

FAQ

Is auto mode safe enough to leave on all the time? Anthropic’s own docs warn that auto mode reduces prompts but doesn’t guarantee safety, and recommend it for tasks where you trust the general direction. Pair it with deny rules for things that must never happen, ask rules for checkpoints like pushes, and the sandbox for an OS-level boundary.

What’s the difference between auto mode and --dangerously-skip-permissions? Auto mode runs a classifier on actions that aren’t plain reads or in-directory edits and blocks risky ones. Bypass mode skips permission prompts and safety checks entirely (apart from a short list of things no mode auto-approves) and is meant only for isolated containers or VMs.

Do I still need allow rules in auto mode? Narrow ones like Bash(npm test) still speed things up, because they resolve before the classifier. Broad ones like Bash(*) are set aside while auto mode is on.

Can a repository I clone turn on bypass or loosen auto mode? Not through its settings files: bypassPermissions and auto as defaultMode, and the autoMode block, aren’t honored from .claude/settings.json or .claude/settings.local.json, and project allow rules wait for the workspace trust dialog. Project hooks and the env block are a different matter in claude -p, so use --setting-sources user or --bare for untrusted repos.

Where do “don’t ask again” approvals go? Bash and WebFetch approvals are saved as rules in .claude/settings.local.json at the repo root. File-edit approvals last until the session ends.

How do I see every rule that’s in effect? Run /permissions in a session. It lists each rule with the settings file it came from, and the Auto mode tab shows classifier rules.

---

Wrapping up

A sensible setup for most developers: keep auto mode for day-to-day work, put "defaultMode" in your user settings if you want something else, add ask rules for git push and gh pr create, deny reads of .env and secrets, turn on the sandbox with failIfUnavailable, and use dontAsk with an explicit --allowedTools list in CI. Once the classifier starts blocking routine work, teach it your infrastructure with autoMode.environment and "$defaults" rather than loosening rules. For more hands-on guides, see the latest tutorials on the 7minai homepage and our guide to writing Claude skills.

Sources

• Choose a permission mode, Claude Code docs. Modes, starting-mode precedence, auto mode requirements, default block/allow lists, fallback thresholds, bypass mode, protected and critical paths.
• Configure permissions, Claude Code docs. Rule syntax and evaluation order, wildcard behavior, Bash rule limits, Read/Edit path patterns, managed settings, workspace trust, headless safety flags.
• Configure auto mode, Claude Code docs. Ask-rule checkpoints, autoMode.environment, $defaults, allow/soft_deny/hard_deny, claude auto-mode subcommands, /auto-mode-setup, classifyAllShell, reviewing denials.
• Configure the sandboxed Bash tool, Claude Code docs. /sandbox, modes, Linux dependencies, filesystem settings, probe commands, failIfUnavailable.
• Claude Code settings, Claude Code docs. Settings scopes and managed settings delivery.
• @anthropic-ai/claude-code on npm. latest 2.1.303 and stable 2.1.292 as of October 19, 2026.
• Our own check of Claude Code 2.1.303 on Linux: claude --help, claude auto-mode defaults and claude doctor output.