Claude CodeのbypassPermissionsでrm確認を止める環境変数と効かない条件

--permission-mode bypassPermissions で動かしているのに、rm -rf だけ確認が出て無人のジョブが止まる。原因は、許可ルールでも承認できない「critical-path削除」の確認が、bypassPermissionsにも残っているからです。

止める変数が CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 です。v2.1.311以降が必要で、claude を起動する環境に置く必要があります。効かない原因はほぼ決まっているので、確認の手順と合わせて並べます。

bypassPermissionsでも出るrm確認の正体

bypassPermissionsは、権限確認と安全チェックを飛ばしてツール呼び出しを即実行するモードです。それでも rm と rmdir のうち、対象がcritical pathと判定されたものは確認が出ます。

critical pathに数えられる対象は次のとおりです。

• ファイルシステムのルートと、その直下のディレクトリ(/usr、/etc、/data など)
• ホームディレクトリ
• 作業ディレクトリとその親
• 追加の作業ディレクトリ配下のglob(rm -rf <dir>/*)。ディレクトリ自体の rm -rf <dir> は対象外

rm -rf "$DIR"/* のように変数の直下にglobや末尾スラッシュが付く形や、rm -rf "$(pwd)" のようにコマンド置換の出力だけが対象の形も、critical pathとして扱われます。変数が空だとルートの削除になるためです。全体像はProtected pathsとCritical pathsの違いで扱っています。

bypassPermissionsでのこの確認は、ターミナルでは承認を求める形で出ます。auto とbypassPermissionsのターミナルでは2分のカウントダウンが付き、時間内に答えないとコマンドは拒否されます。3回続けて時間切れになると、そのセッションでは以降の削除が即座に拒否されます。VS Code拡張のチャット欄とデスクトップアプリでは、PermissionRequest フックが許可しない限り拒否されます。

変数を設定して起動する

変数は claude を起動するシェルで設定します。設定してから --permission-mode bypassPermissions で起動する流れです。

export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

WindowsのPowerShellとCMDでは、設定の書き方が変わります。

$env:CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS = "1"
claude --permission-mode bypassPermissions

set CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

bypassPermissionsは、有効にして起動したセッションでしか使えません。起動時に permissions.defaultMode: "bypassPermissions" か、--permission-mode bypassPermissions、--dangerously-skip-permissions のどれかで入ります。変数だけではモードに入れないので、この前提を先に満たしてください。

settingsのenvブロックでは効かない

変数をsettings.jsonに書いても無視されます。Claude Codeはこの変数を起動環境からしか読まず、どの種類のsettingsファイルでも env ブロックの値を無視するためです。

{
  "env": {
    "CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS": "1"
  }
}

上の設定は書いても効きません。チームで共有するリポジトリのsettingsに入れて全員の削除確認を外す、という使い方ができない設計です。外す責任を、起動する人の環境に残しています。

自分のマシンで常用するなら、~/.zshrc などのプロファイルに export を書く方法もあります。効く範囲は、後述の起動スクリプトで狭められます。

効いているかは起動時の1行で確かめる

変数が働いているかは、起動時にClaude Codeが出す1行で分かります。-p の実行ではstderrに出ます。Agent SDKのアプリでは、stderr オプションを渡すと読めます。

この行が出ていないからといって、確認が有効とは限りません。Agent SDKで stderr オプションを渡していないと、行は見えないまま確認なしで動いている場合があります。

出していない変数の行が出た場合は、シェルのプロファイルなど、どこかで設定されています。見つけて外してください。

動作を試すなら、使い捨てのディレクトリが安全です。空のディレクトリを作ってそこで起動し、作業ディレクトリ自身を指す rmdir をClaudeに実行させます。作業ディレクトリはcritical pathなので、変数なしなら確認が出る想定の操作です。空のディレクトリなので、通っても失うものはありません。変数を付けた起動と付けない起動で同じ操作を試し、確認の出方を見比べると、効いているかどうかが一目で分かります。

設定したのに確認が出る原因

has no effect in this session が出る、または行は出ているのに削除の確認が残る場合は、次の原因を上から確かめます。

バックグラウンドセッションの行は見落としやすい点です。バックグラウンドセッションでbypass permissionsが無視される問題は別の原因ですが、起動経路の違いで挙動が分かれる点は共通しています。

範囲を狭めるなら起動スクリプトに閉じ込める

隔離環境の専用スクリプトに閉じ込めれば、通常の起動には影響しません。例えば、コンテナの中だけで使う次のようなスクリプトです。

#!/usr/bin/env bash
# run-claude-isolated.sh: 使い捨てコンテナの中だけで呼ぶ
export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
exec claude --permission-mode bypassPermissions "$@"

exec で claude に置き換えているので、変数はこの起動にだけ渡ります。手元のマシンでは、変数を含まない別の起動方法を使い分けます。-p で非対話実行する場合も、同じスクリプトから呼べます。ジョブのログに残せば、効いたかどうかを後から追えます。

変数があっても止まらないもの

変数が外すのは、BashとMonitorツールで、critical-path検査に当たった削除の確認だけです。ほかの制限は残ります。

• プランモード: 確認なしで走るのはbypassPermissionsモードそのものだけで、プランモードでは外れません
• Bashとは別の検査: Remove-Item や、cmd 経由の rd、del などは別のチェックを持ちます。bypassPermissionsはPowerShellの作業ディレクトリ削除の確認を飛ばしますが、システムパスとワイルドカードの拒否は全モードで残ります
• denyルール: 一致するdenyルールは削除をブロックします。rm の許可ルールやBashの包括許可は、この検査を通すものではなく、変数の有無に関係しません
• サンドボックス: OSが書き込めるパスを絞る制御は、変数と無関係に効きます

逆向きの注意もあります。確認が出なくなるのは、検査が見つけた削除だけでなく、Claude Codeが解析しきれなかったコマンドも含みます。確認が外れる範囲は、rm -rf ~ の入力より広いと考えてください。

同じ系統の変数との役割分担

CLAUDE_CODE_DISABLE_ で始まる4つの変数は、確認の一部の局面だけを外します。EVEN_MOREは、bypassPermissionsでのcritical-path削除の確認をまとめて外す点が違います。

どれも起動環境から読まれ、settingsのenvでは無視されます。前の4つの使い分けはrm安全プロンプトを環境変数で無効化する方法に、マウントドライブの変数単体はマウントドライブのrm確認を環境変数で止めるにあります。

入れる前に確かめたいこと

この変数を入れると、rm -rf ~ のような削除が、確認なしで走る状態になります。入れてよい環境は、中身を失っても困らない隔離環境です。コンテナや使い捨てVMで、非rootのユーザーで動かす構成が前提になります。Dev Containerの構成はその一例です。

確認だけを外したい理由が「変数付きの rm -rf "$DIR"/* で止まる」なら、変数を入れずに済む手があります。展開を "${DIR:?}"/* のように守ると、変数が空のときはシェルがエラーで止まります。すべての展開をこの形で守った削除は、この検査を通ります。bypassPermissionsなら、ほかのcritical-pathの検査に当たらない限り確認なしで走ります。

反対に、CIのように人が答えられない環境なら、2分で拒否されるより変数で通す方が合う場合もあります。その場合も、削除が走りうる範囲は変数の外側で絞っておきます。

まとめ

bypassPermissionsでも出るrmの確認は、CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 を起動環境に置くと止まります。必要なバージョンはv2.1.311以降で、settingsのenvには書けません。

入れたあとは起動時の1行で効きを確かめ、効かなければ表の原因を上から外していきます。変数なしで済むのは、変数が空の展開を "${DIR:?}" で守れる削除だけです。それ以外の削除を通す前提で入れるなら、失ってよい環境に限る、というのがこの変数の使いどころです。