CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS: Setup and Audit

Leave CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS unset on development machines and shared CI runners. In Claude Code v2.1.311+, it removes a specific deletion prompt only when the session uses bypassPermissions. Reserve it for disposable, isolated environments where losing every writable file is acceptable.

As of 2026-10-28, Anthropic documents this override as a launch-environment setting. It does not enable bypass mode or disable every other permission control.

Why does dangerous mode still block rm -rf ~?

Claude Code checks recognized rm and rmdir targets separately from ordinary tool approvals. The --dangerously-skip-permissions flag selects bypassPermissions, but that mode retains the critical-path check unless the new override takes effect.

An allow rule cannot approve a recognized critical-path removal. Neither can a PreToolUse hook that returns allow. By default, the terminal asks for approval with a two-minute countdown.

In a -p run, a permission tool, SDK callback, or allowing PermissionRequest hook can decide the operation. Without one, the baseline result is denial.

The critical-path definition includes:

• The filesystem root, such as /.
• Direct children of the root, including /usr, /etc, and /data.
• Your home directory, including its Windows 8.3 short name, such as C:\Users\LONGNA~1.
• Windows drive roots and their top-level directories, such as C:\ and C:\Windows. Root spellings such as \\?\C:\ and \\localhost\C$ count too.
• Your working directory and its parents.
• Additional working directories and their parents, specifically when the target is a glob beneath them, such as rm -rf <dir>/*.

Deleting an additional directory itself with rm -rf <dir> does not trigger that additional-directory check. Another rule can still apply, such as the directory also being a top-level path.

This check covers commands Claude Code recognizes. A command it misses receives no special protection, and other approved programs can delete files too. PowerShell Remove-Item and cmd removal commands have separate checks.

Set it for one isolated terminal session

Set the variable in the environment that launches claude, then select bypassPermissions explicitly. A suitable use case is an automated job that intentionally empties a disposable working directory.

Use a working, authenticated CLI at v2.1.311 or later. Run these checks in Bash on macOS, Linux, or WSL:

claude --version
claude auth status --text

If authentication fails, use claude auth login with your approved account setup. If the wrong binary runs, follow the Claude Code installation and PATH checks. Update an older installation before continuing.

Launch the intended session with a temporary Bash assignment:

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions

The assignment applies to this command and its children. It does not persist in the parent shell. You can substitute --dangerously-skip-permissions for --permission-mode bypassPermissions.

Use a non-root user for the isolated environment. On Linux and macOS, bypass mode normally refuses root or sudo launches, with an exception for recognized sandboxes.

Do not put this variable in the env block of ~/.claude/settings.json, .claude/settings.json, or .claude/settings.local.json. The environment-variable reference confirms that Claude Code ignores it there. Moving it between settings scopes will not fix that.

The override applies only while the session is actually in bypassPermissions, not plan. Its scope is the critical-path check in the Bash and Monitor tools, including commands that check cannot fully parse.

To remove an existing exported setting, exit the affected session and remove the assignment from its launch source. Run unset CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS in your shell, then start a new session.

Verify the startup notice without deleting anything

Read Claude Code’s startup notice to check whether the override is eligible to take effect. A successful model response alone does not establish its permission state.

For a small diagnostic in the isolated environment, run this in Bash:

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions \
  --tools "" --disallowedTools "mcp__*" \
  -p "Reply with READY." 2>claude-startup.log

grep -F 'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' claude-startup.log

The CLI flags remove built-in tools and deny MCP tools for this diagnostic. These flags restrict the tools the model can call; startup hooks and extensions still load.

The command requests a READY reply on stdout. It saves startup stderr in claude-startup.log without requesting a deletion.

The documented notices contain one of these three phrases:

Notice fragment	Meaning
is set, so dangerous rm commands can run without a prompt	The override can apply once managed settings and plugin hooks have loaded. Relevant rules or hooks can still prevent it.
has no effect in this session	The usual prompt or denial remains for this session. Correct the cause and restart.
has no effect while the Windows registry cannot be read for managed settings	The usual checks remain while the registry query fails. A later successful query can activate the override without restarting.

In an Agent SDK application, supply its stderr option to receive the notice. Missing output does not prove that the critical-path prompt remains active. Check launch-variable inheritance, the active permission mode, and whether the session was started indirectly.

If the diagnostic exits before a notice appears, inspect the startup error first. An authentication or configuration failure is separate from this permission setting.

Nine reasons the override has no effect

Check the version, launch environment, and active mode before changing any other configuration. Then match your situation to the documented exceptions.

These are alternative causes. Keep deliberate team protections in place.

Cause	What to check and what to do
1. Another component handles permission prompts	Check --permission-prompt-tool or an SDK canUseTool callback without --permission-prompts none. Also check any PermissionRequest hook, regardless of matcher, or a mod handling that event. Remove an unintended handler and restart.
2. The session runs in a graphical chat panel	The VS Code extension’s chat panel and Desktop app do not apply this override. Start the CLI from your own terminal, including an IDE’s integrated terminal.
3. A deny or ask rule targets Bash, Edit, or Read	Any such rule disables the override, even if unrelated to deletion. Once read, its effect lasts for the session even after removal. An approved rule change requires a restart. To omit a tool, use --tools instead of a deny rule.
4. Outside-directory reads are blocked	Check permissions.blockReadsOutsideWorkingDirectories. If disabling it is intended, remove every setting that sets it to true and restart.
5. Claude Code was launched inside another session	Launching through a session’s Bash tool or hook keeps the usual checks, even with the variable on the command line. Start from your own shell. This nested-session restriction is not a security boundary.
6. A PreToolUse hook returns ask	Inspect the hook’s decision for the removal. Correct an unintended ask response; an allow response alone cannot override the ordinary critical-path check.
7. Claude Code created the session	Background sessions, split-pane agent teammates, and sessions created by a Remote Control server start without the variable. Use a directly launched terminal session when this override is required.
8. Managed settings have not loaded successfully	Ask the administrator to repair the failing settings source. Use claude doctor to investigate server-managed fetch failures. Registry-query failures have the separate behavior below.
9. The Windows registry query fails	This applies on Windows and WSL, even when WSL does not use registry settings. Causes include disabled interoperability, non-English Windows, or a container on a WSL2 kernel. Restore interoperability only if permitted; otherwise perform the intended cleanup yourself.

After an authorized change, repeat the startup-notice check. If a Windows hook behaves unexpectedly, use the active-binary and Windows hook checks before changing the permission policy.

Audit launch sources and enforce team policy

Audit both configuration files and the environment of the process that starts Claude Code. A clean repository search cannot establish what a hosted CI system injects.

Find persisted settings and reject them in CI

Search the repository and common shell profiles without printing file contents. The following Bash example requires ripgrep and prints matching filenames:

audit_paths=(.)
for audit_path in \
  "$HOME/.bashrc" "$HOME/.bash_profile" "$HOME/.profile" \
  "$HOME/.zshrc" "$HOME/.zprofile" "$HOME/.zshenv"
do
  if [[ -f "$audit_path" ]]; then
    audit_paths+=("$audit_path")
  fi
done

rg -l --hidden --no-ignore -F \
  -g '!.git/**' -g '!node_modules/**' \
  'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' \
  "${audit_paths[@]}"

Review matches before changing them; a document mentioning the variable is not an active export. Extend the search to sourced profile files, launcher scripts, container definitions, and environment files.

Also inspect CI variables at organization, repository, environment, and job scope. Review the runner service’s environment and any step that changes variables before launching Claude Code. Do not dump the complete environment into logs.

Place this Bash check immediately before the Claude Code invocation in a controlled CI launcher:

if [[ -n "${CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS+x}" ]]; then
  printf '%s\n' 'Refusing Claude Code launch: critical-path override variable is set.' >&2
  exit 1
fi

This rejects any presence, including an empty value or 0. That is a conservative launcher policy, not a claim that every value enables the feature. It protects only invocation paths that actually run the check.

Disable bypass mode through managed settings

Block bypass mode when your team does not need it. Since the override requires that mode, this removes its prerequisite. A managed settings env block cannot neutralize the launch-only variable.

Merge this control into the organization’s active managed settings:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

For file-based delivery, use:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux and WSL: /etc/claude-code/managed-settings.json
• Windows: C:\Program Files\ClaudeCode\managed-settings.json

Restart Claude Code and inspect /status. Confirm that Setting sources names the intended managed source. A new attempt to enter bypassPermissions should be rejected.

Check the selected source before rollout: a higher-ranked managed source can supersede a deployed file. Protect the policy through endpoint administration; someone with local administrator access can edit a file-based policy.

Which protection is more reliable: deny rules or sandboxing?

Use operating-system isolation for filesystem boundaries, with permission rules controlling individual tool calls. The critical-path prompt is an additional check, not complete filesystem protection.

Keep useful deny rules. However, Bash rules match command text: Bash(rm *) does not cover every invocation or another program that deletes files. Review installed hooks and mods too, since extensions can affect permission decisions.

On supported macOS, Linux, and WSL2 systems, merge these sandbox settings into the managed policy:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

This configuration prevents startup when sandboxing is unavailable and disables unsandboxed retries. Native Windows does not support this sandbox, so that policy would prevent startup there.

Inspect /sandbox for effective configuration and dependencies. Audit excludedCommands and writable paths: strict mode still permits exclusions, and user settings or --settings can widen some lists.

Sandboxed commands can still delete writable project data. The built-in boundary also does not contain every hook, locally launched MCP server, or file tool. For unattended work requiring that wider boundary, isolate the whole Claude Code process in a container, VM, or sandbox runtime. Keep valuable host paths out of writable mounts and make the working copy replaceable.