CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS: 設定と監査

開発用マシンや共有の CI ランナー（ジョブを実行する環境）では、CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS を設定しないでください。Claude Code v2.1.311+ では、セッションが bypassPermissions の場合に限り、特定の削除確認を無効にします。書き込み可能なファイルをすべて失ってもよい、使い捨ての隔離環境だけで使用してください。

2026-10-28 時点で、Anthropic はこの設定を起動環境の変数として説明しています。この変数自体がバイパスモードを有効にするわけではありません。他の権限制御をすべて無効にするものでもありません。

危険なモードでも `rm -rf ~` が止まるのはなぜですか？

Claude Code は、認識した rm と rmdir の対象を、通常のツール承認とは別に確認します。--dangerously-skip-permissions は bypassPermissions を選択するフラグです。ただし、このモードでも、新しい設定が有効にならない限り重要なパスの確認は残ります。

重要なパスの削除だと認識された操作は、allow ルールでは承認できません。allow を返す PreToolUse フックでも承認できません。フックとは、指定されたイベントで実行する処理のことです。既定では、ターミナルに2分のカウントダウン付きで承認要求が表示されます。

-p で実行する場合は、権限ツール、SDK のコールバック、または許可を返す PermissionRequest フックが操作を判断できます。これらがなければ、既定の結果は拒否です。

重要なパスとは、削除時にこの確認の対象になるディレクトリです。重要なパスの定義には、次の場所が含まれます。

ファイルシステムのルート。例は / です。
ルート直下のディレクトリ。/usr、/etc、/data などです。
ホームディレクトリ。Windows 8.3 形式の短い名前も対象です。例は C:\Users\LONGNA~1 です。
Windows ドライブのルートと、その直下のディレクトリ。C:\ や C:\Windows が該当します。\\?\C:\ や \\localhost\C$ というルートの表記も対象です。
作業ディレクトリと、その上位にある親ディレクトリです。
追加の作業ディレクトリと、その上位にある親ディレクトリ。ただし、削除対象がその配下の glob パターンの場合に限ります。これはワイルドカードで対象を指定するパターンで、例は rm -rf <dir>/* です。

追加したディレクトリ自体を rm -rf <dir> で削除しても、追加ディレクトリに関するこの確認は発生しません。ただし、別の条件に該当する場合は確認対象になります。たとえば、そのディレクトリがルート直下にある場合です。

この確認が扱うのは、Claude Code が認識したコマンドです。見逃したコマンドには特別な保護がなく、承認済みの別のプログラムでもファイルを削除できます。PowerShell の Remove-Item と cmd の削除コマンドには、それぞれ別の確認があります。

隔離したターミナルセッションだけに設定します

claude を起動する環境で変数を設定し、bypassPermissions を明示的に選択してください。使い捨ての作業ディレクトリを意図的に空にする自動ジョブなどが、適した用途です。

すでに動作し、アカウントの認証も済んでいる CLI を使ってください。必要なバージョンは v2.1.311 以降です。macOS、Linux、WSL では、Bash で次の2つのコマンドを実行し、バージョンと認証状態を確認します。

claude --version
claude auth status --text

認証に失敗した場合は、承認済みのアカウント設定で claude auth login を実行してください。違う実行ファイルが起動する場合は、Claude Code のインストールと PATH の確認手順を参照してください。古いバージョンなら、更新してから先に進みます。

Bash の一時的な変数代入を使って、対象のセッションを起動します。

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions

この代入で渡す値は、ここで起動するコマンドと、そのコマンドから起動する子プロセスに適用されます。コマンドを起動した親シェルの設定としては残りません。--permission-mode bypassPermissions の代わりに --dangerously-skip-permissions も使えます。

隔離環境では、root 以外のユーザーを使ってください。Linux と macOS では、バイパスモードは通常、root または sudo による起動を拒否します。ただし、認識されたサンドボックスには例外があります。

この変数を ~/.claude/settings.json、.claude/settings.json、.claude/settings.local.json の env ブロックに入れないでください。環境変数のリファレンスでも、Claude Code がその設定を無視すると明記されています。設定の適用範囲を変えても解決しません。別の設定ファイルの env に移しても、この変数の読み取り元は変わらないためです。

削除確認の無効化は、実際に bypassPermissions で動いている間だけ適用されます。plan では適用されません。対象は Bash と Monitor ツールの重要なパスの確認で、その確認処理が完全には解析できないコマンドも含みます。

すでにエクスポートした設定を取り除く場合は、対象のセッションを終了し、起動元から変数の代入を削除します。シェルで unset CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS を実行し、新しいセッションを開始してください。

削除せずに起動通知を確認します

Claude Code の起動通知を読み、この設定が有効になり得る状態か確認してください。モデルが正常に応答しただけでは、権限の状態は判断できません。

隔離環境で簡単な診断を行うには、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

この診断では、CLI のフラグが組み込みツールを利用対象から外し、MCP ツールを拒否します。制限されるのは、モデルが呼び出せるツールです。起動時のフックと拡張機能は引き続き読み込まれます。

コマンドは、標準出力である stdout に READY と応答するようモデルへ要求します。削除を依頼せずに、起動時の標準エラー出力である stderr を claude-startup.log に保存します。

文書化された起動通知には、次の3つの表現のいずれかが含まれます。表中の管理設定は、組織の管理者が適用する設定を指します。

通知の一部	意味
`is set, so dangerous rm commands can run without a prompt`	管理設定とプラグインのフックを読み込んだ後に、削除確認の無効化を適用できます。関連するルールやフックによって、適用されない場合もあります。
`has no effect in this session`	このセッションでは、通常の確認または拒否が残ります。原因を修正して再起動してください。
`has no effect while the Windows registry cannot be read for managed settings`	レジストリの照会に失敗している間は、通常の確認が残ります。後の照会が成功すると、再起動せずに設定が有効になる場合があります。

Agent SDK を使うアプリでは、通知を受け取るために stderr オプションを指定してください。出力が見えなくても、重要なパスの削除確認が有効なままとは限りません。SDK 側でこの出力を受け取っていないだけの場合もあります。変数が起動元からそのセッションへ継承されているか確認してください。実際に有効な権限モードと、自分のターミナル以外から間接的に起動されたセッションではないかも調べます。

通知が出る前に診断が終了した場合は、まず起動エラーを調べてください。認証や構成の失敗は、この権限設定とは別の問題です。

設定が効かない9つの原因

他の構成を変更する前に、バージョン、起動環境、有効なモードを確認してください。そのうえで、自分の状況を文書化された例外と照合します。

以下は、それぞれ別の原因です。すべての対処を順番に実行する必要はありません。自分の状況に当たる項目を調べ、チームが意図して設けた保護は維持してください。

原因	確認事項と対処
1. 別の仕組みが権限要求を処理している	`--permission-prompts none` を指定せずに、`--permission-prompt-tool` または SDK の `canUseTool` コールバックを使っていないか確認します。`PermissionRequest` フックは `matcher` に関係なく確認対象です。そのイベントを処理する mod も調べます。意図せず有効になった処理を取り除き、再起動してください。
2. セッションがグラフィカルなチャットパネル内で動いている	VS Code 拡張機能のチャットパネルと Desktop アプリでは、この設定は適用されません。自分のターミナルから CLI を起動してください。IDE の統合ターミナルでも構いません。
3. Bash、Edit、Read に対する `deny` または `ask` ルールがある	削除に無関係でも、この種のルールがあると設定は無効になります。起動時に存在する場合も、セッション途中で読み込まれる場合も同じです。読み込まれた後は、ルールを削除してもそのセッション中は無効のままです。承認されたルール変更の後は再起動してください。ツールを利用対象から外すなら、`deny` ルールではなく `--tools` を使います。
4. 作業ディレクトリ外の読み取りが禁止されている	`permissions.blockReadsOutsideWorkingDirectories` を確認します。無効にする意図がある場合は、これを `true` にしている設定をすべて取り除き、再起動してください。
5. 別のセッション内から Claude Code を起動した	セッションの Bash ツールやフックから起動すると、通常の確認が残ります。コマンドラインに変数を付けても同じです。自分のシェルから起動してください。この入れ子セッションの制限は、安全を保証する境界にはなりません。
6. `PreToolUse` フックが `ask` を返す	削除操作に対するフックの判断を調べます。意図しない `ask` 応答を修正してください。`allow` を返すだけでは、通常の重要なパスの確認を無効にできません。
7. Claude Code 自身がセッションを作成した	Claude Code が作るバックグラウンドセッションは、この変数なしで起動します。分割ペインで動くエージェントチームのメンバーや、Remote Control サーバーが作るセッションも同様です。この設定が必要なら、ターミナルから直接セッションを起動してください。
8. 管理設定の読み込みに成功していない	失敗している設定元を修復するよう管理者に依頼してください。サーバー管理設定の取得失敗は `claude doctor` で調べます。レジストリ照会の失敗は、次の行に示す別の動作になります。
9. Windows レジストリの照会に失敗する	Windows と WSL が対象で、WSL がレジストリ設定を使っていない場合にも該当します。原因には、相互運用機能の無効化、英語以外の Windows、WSL2 カーネル上のコンテナなどがあります。許可されている場合だけ相互運用機能を復旧してください。それ以外の場合は、必要な削除を自分で行います。

許可された変更の後は、起動通知をもう一度確認してください。Windows のフックが想定外の動作をする場合は、権限ポリシーを変える前に実行中のバイナリと Windows フックの確認手順を使って調べます。

起動元を監査してチームのポリシーを適用します

設定ファイルと、Claude Code を起動するプロセスの環境の両方を監査してください。リポジトリ内の検索に何も出なくても、ホスト型 CI サービスが注入する変数までは確認できません。

永続的な設定を探し、CIで起動を拒否します

ファイル内容を表示せずに、リポジトリと一般的なシェル設定ファイルを検索します。次の Bash の例には ripgrep が必要です。一致する内容があるファイルの名前だけを表示します。

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[@]}"

一致した箇所は、変更する前に確認してください。文書に変数名が書かれていても、実際にエクスポートされているとは限りません。シェル設定から別のファイルを読み込んでいる場合は、そのファイルも確認対象です。起動スクリプト、コンテナ定義、環境変数を設定するファイルにも検索を広げてください。

CI の変数は、組織全体の設定に加え、リポジトリ単位、環境単位、個々のジョブの設定でも確認してください。ランナーサービスの環境と、Claude Code の起動前に変数を変更する処理も調べます。環境変数の全内容をログへ出力しないでください。

管理された CI 起動スクリプトでは、Claude Code を呼び出す直前に次の Bash の確認を置きます。

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

この確認は、空の値や 0 を含め、変数が存在するだけで起動を拒否します。これは起動スクリプト側の慎重な方針です。どの値でも機能が有効になるという意味ではありません。この確認を実行してから Claude Code を起動する経路だけが保護されます。確認を含まない別の起動経路には、このスクリプトの拒否は適用されません。

管理設定でバイパスモードを無効にします

チームで必要ない場合は、バイパスモード自体を禁止してください。この変数はそのモードを必要とするため、前提条件を取り除けます。管理設定の env ブロックでは、起動環境だけで読み取られる変数を無効にできません。

組織で有効な管理設定に、既存の設定を残したまま次の制御を追加します。

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

ファイルで配布する場合は、次の場所を使います。

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

Claude Code を再起動し、/status を確認します。Setting sources に、意図した管理設定の取得元が表示されていることを確かめてください。そのうえで、改めて bypassPermissions に入ろうとすると拒否されることを確認します。

展開前に、どの設定元が選ばれるか確認してください。優先順位の高い管理設定元が、配布したファイルに優先する場合があります。端末管理の仕組みでポリシーを保護してください。ローカル管理者権限を持つ人は、ファイル形式のポリシーを編集できます。

拒否ルールとサンドボックスでは、どちらが確実ですか？

ファイルシステムへのアクセス範囲は、OS の隔離機能で制限してください。権限ルールは、個々のツール呼び出しを制御します。重要なパスの削除確認は追加の確認であり、ファイルシステム全体を保護する仕組みではありません。

有用な deny ルールは維持してください。ただし、Bash のルールはコマンドの文字列と照合します。Bash(rm *) は、すべての呼び出し方や、ファイルを削除する別のプログラムを対象にできません。拡張機能が権限判断に影響する場合もあるため、インストール済みのフックと mod も確認します。

対応する macOS、Linux、WSL2 では、次のサンドボックス設定を管理ポリシーに追加してください。

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

この構成は、サンドボックスを利用できない場合に起動を止め、サンドボックス外での再試行を無効にします。ネイティブ Windows はこのサンドボックスに対応していないため、このポリシーを適用すると起動できなくなります。

/sandbox で、実際に有効な構成と依存関係を確認してください。excludedCommands と書き込み可能なパスも監査します。厳格モードでも、除外されたコマンドまで一律にサンドボックスへ入るわけではありません。除外設定は引き続き利用でき、ユーザー設定や --settings によって一部のリストを広げられます。

サンドボックス内のコマンドでも、書き込み可能なプロジェクトデータは削除できます。組み込みの隔離境界は、すべてのフック、ローカルで起動する MCP サーバー、ファイル操作ツールを囲むものでもありません。

より広い境界が必要な無人実行では、Claude Code のプロセス全体をコンテナ、VM、またはサンドボックス実行環境に隔離してください。ホスト上の重要なパスを書き込み可能な状態でマウントせず、作業コピーは作り直せる状態にします。

危険なモードでも rm -rf ~ が止まるのはなぜですか？