Table of Contents
- 1. What Is "Bypass" in the First Place?
- 2. The Real Reason: The 2-Layer Permission System
- 3. Layer 1: Tool Permission UI (Bypass-Controllable)
- 4. Layer 2: AI Safety Judgment (Not Bypass-Controllable)
- 5. Operation Patterns Where Claude Asks on Its Own
- 6. Why Two Layers? The Design Philosophy
- 7. Practical Ways to Reduce Confirmation Prompts
- 8. Summary
- FAQ
You've set the --dangerously-skip-permissions flag in Claude Code, yet Claude still sends a message in the chat asking "Is it okay to run this operation?" Sound familiar?
The instinct is to think "the bypass isn't working" — but that's not what's happening. Claude Code's permission system has two independent layers, and bypass mode only controls one of them.
This article covers everything from "what bypass actually is" to the difference between both permission layers, the types of operations where Claude asks on its own, and practical ways to reduce confirmation prompts when automating.
1. What Is "Bypass" in the First Place?
In software, "bypass" means skipping the normal confirmation or approval flow to proceed directly. Think of a shopping site's "buy now" button that skips the review screen — that's a bypass of the confirmation flow.
In Claude Code's Manual mode (config value default), a confirmation dialog appears before any file edit or shell command is executed. From Claude Code v2.1.283, though, terminal and VS Code sessions start in Auto mode by default on every plan and provider, where a classifier reviews most actions instead of prompting you (on earlier versions, only Pro, Max, and Team plans started in Auto; sessions start in Manual where an administrator has turned auto mode off or the model doesn't support it).
# Manual mode: confirmation before each action
$ claude --permission-mode default
> Please fix index.js
[Claude Code] May I edit index.js? → choose Yes / NoThe permission bypass mode skips (bypasses) this confirmation flow.
# Bypass mode: almost no confirmation dialogs
$ claude --dangerously-skip-permissions
# or
$ claude --permission-mode bypassPermissionsNote that the flag includes the word dangerously. Anthropic positions this mode as intended for containers or isolated environments only — it's not recommended for everyday local development. For a full breakdown of bypass mode risks, see Claude Code Bypass Permission Mode: Risks and Safe Usage.
If confirmation dialogs keep appearing, first check whether you are actually running in bypass. While bypass is active, the terminal status bar shows ⏵⏵ bypass permissions on. If it doesn't, there are two common causes.
- You set it in project settings:
bypassPermissionsas thedefaultModein.claude/settings.jsonor.claude/settings.local.jsondoesn't take effect, and the session starts in Manual mode (v2.1.257 and later). Put it in your user settings (~/.claude/settings.json) or managed settings, or pass the flag at launch - You tried to switch mid-session: bypass can only be selected in a session that had it enabled at launch. In a session started without it, pressing Shift+Tab never reaches bypass
Also, the first time you start an interactive session in bypass, Claude Code shows a one-time warning asking you to accept responsibility for actions taken without permission checks (your acceptance is saved to user settings).
2. The Real Reason: The 2-Layer Permission System
The answer to "why does confirmation appear even with bypass enabled" is that Claude Code's permission system is built on two independent layers.
Claude Code Permission System: 2-Layer Architecture
Bypass mode can only disable "Layer 1" (and even Layer 1 keeps a few prompts)
--dangerously-skip-permissions disables almost all of Layer 1 (ask rules, critical-path deletions and a few others remain). Layer 2 cannot be bypassed.
Confusing these two layers is the root cause of the "bypass isn't working" misconception. Let's look at each in detail.
3. Layer 1: Tool Permission UI (Bypass-Controllable)
The first layer is the confirmation dialog shown before tool execution — the interactive UI that appears when Claude Code is about to edit a file or run a shell command.
| Tool | Example Confirmation Dialog |
|---|---|
| File edit | "May I modify index.js?" |
| Bash execution | "May I run npm install?" |
| Web access | "May I access https://...?" |
This is exactly the layer that bypass mode disables. With --dangerously-skip-permissions, dialogs like these almost never appear and Claude can execute tools freely. Even writes to protected paths such as .git and .claude go through without a prompt in bypass. In this sense, bypass mode is working correctly.
Prompts that still appear in bypass (Layer 1 exceptions)
"Almost" is the key word. The official documentation states that Claude Code doesn't auto-approve the following in any mode, including bypass (source: Claude Code's official "Choose a permission mode", as of September 22, 2026).
- Actions matching an ask rule: anything you listed under
permissions.askin your settings (for example,Bash(git push *)) prompts every time, even in bypass - Tools that need your input:
AskUserQuestion, where Claude asks you a multiple-choice question; MCP tools marked as requiring user interaction; and connector tools your organization set to ask rmandrmdiraimed at critical paths: removals targeting the filesystem root and its top-level directories (such as/usr), your home directory, or your working directory and its parents. The docs call this a circuit breaker that guards against model error, and no allow rule or hook can approve it. However, in the Desktop app and VS Code, from v2.1.309 these commands are denied immediately without a prompt, and the denial returns hints for rewriting the command so that sessions with no one present aren't stalled (official changelog)- Others: the cross-session messaging safeguards, and Bash commands that read outside your working directories while
permissions.blockReadsOutsideWorkingDirectoriesis on
Rules matter too. Deny rules still apply in bypass and block matching actions. Allow rules, on the other hand, have no effect in bypass (everything already goes through). In non-interactive runs with -p, these few prompts are denied instead of waiting for input.
Note: There Are 6 Permission Modes
Claude Code has six permission modes: Manual (default), Accept edits (acceptEdits), Plan (plan), Auto (auto), and Bypass permissions (bypassPermissions), plus dontAsk, which never appears in the Shift+Tab cycle and auto-denies anything that would prompt (meant for CI). Bypass (bypassPermissions) is the least restrictive. For details on each mode, see the permission modes explainer.
4. Layer 2: AI Safety Judgment (Not Bypass-Controllable)
The second layer is Claude's autonomous safety judgment. This is completely separate from the tool confirmation UI.
When Claude determines that an operation might have significant consequences, it sends a confirmation message in the chat as plain text. This is not a tool execution mechanism — it's Claude's conversational behavior as an AI.
--dangerously-skip-permissions skips the Layer 1 UI dialogs, but it has no effect on this Layer 2 AI judgment — because Layer 2 is a behavioral principle built into Claude's model itself.
Common Misconception
"I set bypass mode but Claude stopped → bypass isn't working"
→ More accurately, tell them apart by how Claude stopped. If Claude asked in chat text, "Layer 1 UI is disabled, but Layer 2 AI judgment is requesting confirmation." If a dialog asking for permission appeared in the terminal, it's one of the Layer 1 prompts bypass keeps, such as an ask rule or a critical-path deletion. Either way, bypass is working fine (if neither applies and prompts keep coming, you may not have started in bypass at all).
Layer 2 is not a safety guarantee, though. Whether Claude asks is a judgment call in the moment, and it won't necessarily stop before a dangerous action. The official documentation also warns that bypass offers no protection against prompt injection or unintended actions. For anything that must never run, block it with a deny rule.
5. Operation Patterns Where Claude Asks on Its Own
Operations by Type: Which Layer Handles Confirmation?
Layer 1 (Tool permission UI) vs Layer 2 (AI Safety Judgment)
Claude's internal criteria for "I should confirm this" fall into three main categories.
① Irreversibility
Operations that can't be undone make Claude cautious. Permanent file deletion, git push --force, and DROP TABLE are prime examples. Because mistakes are hard to recover from, Claude pauses and asks.
② Blast Radius
Actions that affect production environments, large numbers of files, or other users trigger more frequent checks. Changing one local file rarely prompts a question; modifying a production DB schema almost always does.
③ Security Risk
Operations that send .env files, auth tokens, or API keys externally are flagged as high security risk by Claude, which will ask before proceeding.
Some deletions, however, are not left to Claude's judgment at all: rm and rmdir aimed at critical paths such as the root, your home directory, or the working directory itself are stopped by Claude Code itself (Layer 1), even in bypass (the CLI shows a prompt, while the Desktop app and VS Code deny them outright from v2.1.309). It's one of the few prompts bypass doesn't remove.
These judgments are baked into Claude's AI model and cannot be fully switched off via config. For more on how AI agents are designed to operate safely, see What Is an AI Agent?.
6. Why Two Layers? The Design Philosophy
Why Two Layers? — Design Philosophy
Understanding it through a contractor analogy
Here's an analogy that makes the two-layer design intuitive.
Imagine you hire a contractor to renovate a room and give them a spare key, saying "you can do whatever you need to." That's equivalent to granting tool permissions.
But when the contractor is about to knock down a wall and asks "Is this a load-bearing wall? Are you sure you want me to remove it?" — they're asking based on their own professional judgment, not because they lost the key.
Giving them a key does not stop the contractor from thinking. Their professional judgment and safety awareness operate independently of the key.
Claude works the same way. Bypass mode gives Claude "the key to use tools," but it does not stop Claude's AI judgment. In fact, Claude pausing before high-risk operations is an intentional safety feature, not a malfunction.
7. Practical Ways to Reduce Confirmation Prompts
In CI/CD pipelines and other automation scenarios, you may need Claude to complete tasks without stopping. Here are the most effective approaches.
Approach 1: Use CLAUDE.md to Provide Context
Create a CLAUDE.md file at your project root explaining the environment and constraints. When Claude understands "this is a safe, isolated environment," confirmation frequency drops significantly.
# About This Environment
This repository runs inside a CI/CD pipeline test environment.
- Runtime: fully isolated Docker container
- Production impact: none
- All changes are rollback-safe
Please proceed without asking for extra confirmation.Approach 2: Give Small, Specific Instructions
Vague instructions increase Claude's uncertainty and trigger more confirmations.
| Instruction Type | Example | Confirmation Rate |
|---|---|---|
| Vague | "Clean up this project" | High |
| Specific | "Remove the unused imports in src/" | Low |
| Vague | "Deploy it" | High |
| Specific | "Run npm run deploy:staging on the staging environment" | Low |
Approach 3: Try Auto Mode First
Before reaching for full bypass mode, try auto mode. It runs a safety classifier in the background while auto-approving most operations, and it also nudges Claude to keep working instead of stopping for clarifying questions (Claude still asks when your prompt or a skill relies on it). If the only reason you're using bypass is "I'm tired of confirmation prompts," auto mode may be enough. Actions matching an ask rule still prompt in auto mode.
Important Caveat
No configuration can reduce Claude's safety judgment to absolute zero. This is intentional — not a bug or limitation. For high-risk operations, Claude asking for confirmation is correct behavior. Accept it as part of the design. Layer 1, too, keeps a few prompts that bypass doesn't remove, such as ask rules and critical-path deletions.
8. Summary
| Item | Detail |
|---|---|
| What bypass is | Skipping almost all pre-tool confirmation dialogs (Layer 1) |
| What bypass disables | Tool Permission UI ("May I run this command?"), including prompts for writes to protected paths such as .git and .claude |
| What bypass does NOT disable | Claude's AI safety judgment (confirmation sent as chat text) and the Layer 1 exceptions (ask rules, rm/rmdir on critical paths, AskUserQuestion) |
| Rules under bypass | Deny still blocks; allow has no effect |
| Claude's confirmation criteria | Irreversibility, blast radius, security risk |
| How to reduce confirmations | CLAUDE.md context / specific instructions / auto mode |
| Why two layers | Tool permission and AI judgment are fundamentally separate concepts |
When Claude asks for confirmation even in bypass mode, it's not that bypass has stopped working — two independent systems are simply doing their jobs. Understanding this distinction helps you predict Claude Code's behavior accurately and use it more efficiently.
To understand the differences across Claude products, see Claude.ai vs Claude Code: What's the Difference?.
FAQ
Can I get zero confirmations with bypass mode?
You can disable almost all tool execution UI dialogs (Layer 1), but the prompts for actions matching an ask rule, for rm or rmdir on critical paths, and for questions via AskUserQuestion remain. You also cannot completely eliminate Layer 2 AI safety judgment confirmations. This is an intentional safety feature. However, carefully documenting your environment in CLAUDE.md and giving specific instructions can significantly reduce how often Claude asks.
Is Claude asking for confirmation a bug?
No. Bypass mode skips the tool permission UI, not Claude's AI judgment. Claude pausing before irreversible operations, production environments, or sensitive data is intentional safety behavior — not a malfunction. It's not "bypass not working," it's "two systems running independently." If a dialog asking for permission appears instead of chat text, it's one of the Layer 1 prompts bypass keeps, such as an ask rule or a critical-path deletion.
How do I stop Claude from pausing in CI/CD pipelines?
Three things work well: ① Explicitly state in CLAUDE.md or the system prompt that "this is a fully isolated CI/CD environment and all operations run safely," ② give small, specific task instructions (vague instructions trigger more confirmations), ③ combine bypass mode with Docker container isolation. For ③, run Claude Code as a non-root user: on Linux and macOS, bypass refuses to start as root or under sudo. With -p, the few prompts bypass keeps are denied instead of waiting for input. If you only want pre-approved actions to run, the official docs also list --permission-mode dontAsk with --allowedTools for CI. Note that some pausing may still occur even with all of this in place.
Can I visually tell apart a tool dialog and Claude's confirmation?
Yes. Layer 1 tool permission dialogs appear in the Claude Code terminal as interactive UI that shows the command or edit along with choices such as Yes and No. Layer 2 AI judgment confirmations appear as regular conversation text from Claude (e.g., "This will modify the production DB — is that okay?"). The confusing one is AskUserQuestion, where Claude asks a multiple-choice question: the question comes from Claude, but it appears as a dialog and waits for your answer even in bypass, because Layer 1 never auto-approves it. The display formats differ, so they're easy to distinguish once you're familiar.
