すべてのモードがデフォルトサイクルに含まれるわけではありません。

• auto：auto モードが利用可能な場合に表示されます。auto へのサイクルは確認プロンプトなしで権限モードを切り替えます
• bypassPermissions：--permission-mode bypassPermissions、--dangerously-skip-permissions、--allow-dangerously-skip-permissions、または ユーザー、--settings、または管理設定の permissions.defaultMode: "bypassPermissions" で開始した後に表示されます。--allow- バリアントはモードをサイクルに追加しますが、アクティブ化しません
• dontAsk：サイクルに表示されることはありません。--permission-mode dontAsk で設定します

有効なオプションモードは plan の後にスロットインし、bypassPermissions が最初で auto が最後です。両方が有効な場合、bypassPermissions から auto へのサイクルを通過します。

Bash 権限プロンプトから：Manual と acceptEdits 権限モードで、auto モードが利用可能な場合、Claude Code は Bash コマンドの権限プロンプトに Yes, and switch to auto mode を追加します。それを選択してコマンドを承認し、セッションを auto モードに切り替えます。PowerShell ツールプロンプトはオプションを提供しません。Claude Code v2.1.247 以降が必要です。

Claude Code は、ask ルールの 1 つによって強制されたプロンプト、または フックによるプロンプトにはオプションを追加しません。auto モードは依然としてそれらのプロンプトを表示するため、切り替えてもそれらは削除されません。

起動時：権限モードをフラグとして渡します。

claude --permission-mode plan

デフォルトとして：異なる権限モードで開始するで説明されているように、必要なスコープで permissions.defaultMode を設定します。

同じ --permission-mode フラグは 非対話的実行用に -p で機能します。

VS Code

セッション中：プロンプトボックスの下部にあるモード指示器をクリックします。このページのモードに対して以下のラベルを使用します。

デフォルトとして：権限モード会話が開始するようにピンするには、VS Code ユーザー設定で claudeCode.initialPermissionMode を default、manual、acceptEdits、plan、または bypassPermissions に設定します。設定は auto を受け入れません。Auto で開始するには、設定を解除したままにして、以下の項目 2 で説明されているようにモード指示器から Auto を 1 回選択します。拡張機能は以下の最初に適用されるものでそれぞれの新しい会話を開始します。

1. claudeCode.initialPermissionMode
2. モード指示器から最後に選択したモード（Manual、Edit automatically、または Auto の場合）。Plan または Bypass permissions を選択すると、その会話のみに適用されます
3. 管理設定または ~/.claude/settings.json からの permissions.defaultMode
4. プラン、プロバイダー、組織設定の組み込みデフォルト

拡張機能は開始権限モードのためにプロジェクトの .claude/settings.json または .claude/settings.local.json を読み込むことはありません。claudeCode.claudeProcessWrapper が設定されている場合、項目 3 と 4 は適用されません。それらの会話は、項目 1 または項目 2 が権限モードを設定しない限り Manual で開始します。

v2.1.283 より前では、項目 3 は Pro、Max、Team プランでのみ フィーチャーフラグ取得を行うセッションに適用されました。

Auto は auto モードが利用可能な場合、モード指示器に表示されます。

Bypass permissions には拡張機能設定の Allow dangerously skip permissions トグルが必要です。それなしでは、権限モードは指示器に表示されず、項目 1 または項目 3 からの bypassPermissions 値は会話を Manual で開始します。同様に、auto モードが利用できない場合、項目からの Auto は会話を Manual で開始します。

拡張機能固有の詳細については、VS Code ガイドを参照してください。

JetBrains

JetBrains プラグインは IDE ターミナルで Claude Code を実行するため、権限モードの切り替えは CLI と同じように機能します。Shift+Tab を押してサイクルするか、起動時に --permission-mode を渡します。

Desktop

セッション中：Code タブで、プロンプトボックスの下の行にあるモードセレクターを使用します。すべてのモードがセレクターに表示されるわけではありません。

• Auto：auto モードが利用可能な場合に表示されます
• Bypass permissions：Pro と Max プランの Desktop 設定で Allow bypass permissions mode トグルが必要です。Team と Enterprise プランでは、組織ポリシーがそれを制御します

Cowork はこれらのモードを使用しません。Cowork には独自の権限モードがあり、別々に有効化されます。また、デフォルト以外のモードがアカウントで有効化されるまで、モードセレクターはまったく表示されません。Cowork ドキュメントを参照してください。

Desktop 固有の詳細については、Desktop ガイドの 権限モードを選択するを参照してください。

デフォルトとして：設定で defaultMode を設定します。デスクトップアプリは CLI と同じ設定ファイルを読み取り、新しいローカルセッションに権限モードを適用します。

モードセレクターで選択したモードはフォルダごとに記憶され、そのフォルダの defaultMode より優先されます。Plan は例外です。それを選択すると現在のセッションのみに適用されます。

defaultMode が設定ファイルのどこに行くかについては、異なる権限モードで開始するの例を参照してください。

Web and mobile

claude.ai/code では、プロンプトボックスの下の行にあるモードドロップダウンを使用します。モバイルアプリでは、プロンプトボックスの + ボタンをタップし、次に Permission をタップします。クラウドセッションと Remote Control セッションでは、提供される権限モードが異なります。

• クラウドセッション：Accept edits、Plan、Auto。Accept edits は default モードに対応します。クラウドセッションはモードに関係なくファイル編集を事前承認するため、ドロップダウンは Manual の代わりに Accept edits を表示します。クラウドセッションは設定からの defaultMode: "acceptEdits" を引き続き尊重します。Auto モードは組織がそれを許可し、選択されたモデルがそれをサポートする場合にのみ表示されます。Bypass permissions は利用できません。
• ローカルマシンの Remote Control セッション：自分で開始したセッションの場合は Manual、Accept edits、Plan、Auto を使用でき、アプリから Bypass permissions を選択することはできません。Auto を使用するには、セッションが auto モードの利用要件を満たしている必要があります。コンピューター上で実行されるプロジェクトスレッドについては、スレッドを自分のコンピューター上で実行するを参照してください。
  • Bypass permissions を除き、ドロップダウンはローカルセッションの現在の権限モードを表示します。これにはターミナルから設定された権限モードも含まれます。アプリまたはターミナルで権限モードが変更されると、表示が更新されます。
  • デスクトップアプリまたは VS Code 拡張機能でホストされるセッションは、ターミナルでホストされるセッションと同様に、権限モードの変更を発生時に claude.ai に報告します。

Remote Control の場合、ローカルマシンを実行するセッションは claude.ai アカウントでサインインする必要があります。API キーはサポートされていません。ローカルセッションを起動するときに開始権限モードを設定することもできます。

claude remote-control --permission-mode acceptEdits

acceptEdits モードでファイル編集を自動承認する

acceptEdits モードでは Claude はプロンプトなしに作業ディレクトリ内のファイルを作成および編集できます。このモードがアクティブな間、ステータスバーは ⏵⏵ accept edits on を表示します。

ファイル編集に加えて、acceptEdits モードは一般的なファイルシステム Bash コマンドを自動承認します。mkdir、touch、rm、rmdir、mv、cp、sed。touch を除き、これらのコマンドは LANG=C または NO_COLOR=1 のような安全な環境変数、または timeout、nice、nohup のようなプロセスラッパーでプレフィックスされた場合にも自動承認されます。ファイル編集と同様に、自動承認は作業ディレクトリまたは additionalDirectories 内のパスにのみ適用されます。

次の場合は引き続きプロンプトが表示されます。

• そのスコープ外のパス
• 保護されたパス への書き込み
• 認識された rm と rmdir による 重要なパスの削除
• 単純なファイルパス以外のものを伴う touch（たとえばオプション、glob、timeout 5 や LANG=C のようなプレフィックス）
• 組み込みの読み取り専用セット を除くその他すべての Bash コマンド

各パスは シンボリックリンクチェック も通過するため、そのスコープ外に解決される書き込みも自動承認されません。

PowerShell ツール が有効な場合、acceptEdits モードはスコープ内のパスに対して Set-Content、Add-Content、Clear-Content、Remove-Item も自動承認し、それらの一般的なエイリアスも承認します。同じスコープと保護されたパスのルールが適用され、Remove-Item は 独自のチェック を取得します。Set-Content .\notes.txt "It's done" のようなアポストロフィを含む引用符を含む位置引数は、Claude Code が引用符付きと引用符なしの読み取りが異なるため、スコープ内のパスでもプロンプトが表示されます。-Value のような名前付きパラメーターを通じてコンテンツを渡してプロンプトを回避します。

事実後にエディターまたは git diff 経由で変更をレビューしたい場合、各編集をインラインで承認するのではなく acceptEdits を使用します。

Manual モードから Shift+Tab を 1 回押して入るか、直接開始します。

claude --permission-mode acceptEdits

plan モードで編集前に分析する

plan モードは、Claude に変更を加えずに調査と変更の提案を行うよう指示します。Claude はファイルを読み取り、シェルコマンドを実行して調査し、計画を作成しますが、ソースは編集しません。bypass permissions が利用可能なインタラクティブなターミナルセッションを除き、計画を承認するまで編集はブロックされたままです。

計画中のシェルコマンドがどう扱われるかはセッションによって異なり、以下のケースのうち最初に該当するものが適用されます。

• bypass permissions が利用可能なインタラクティブなターミナルセッション: 計画中のコマンドには分類器もプロンプトも適用されません。それでもプロンプトが表示されるいくつかの操作については、bypassPermissions モードですべてのチェックをスキップするを参照してください。
• auto モードが利用可能で、useAutoModeDuringPlan 設定がオン（デフォルトでオン）: 分類器が、クリティカルパスの削除以外のシェルコマンドを、プロンプトを表示する代わりにレビューします。承認されたコマンドは実行され、拒否されたコマンドはブロックされます。
• auto モードが利用できない、または useAutoModeDuringPlan がオフ: 組み込みの読み取り専用セットに含まれないコマンドは、サンドボックスの auto-allow モードが有効な場合も含めて、承認を求めるプロンプトが表示されます。

plan モードに入るには、Shift+Tab を押すか、単一のプロンプトの先頭に /plan を付けます。CLI から plan モードで開始することもできます。

claude --permission-mode plan

計画を承認せずに plan モードを終了するには、もう一度 Shift+Tab を押します。

計画をレビューして承認する

計画の準備ができると、Claude はそれを提示し、どのように進めるかを尋ねます。そのプロンプトから次の選択肢を選べます。

• Yes, and use auto mode: 承認して auto モードで開始します。組織が無効にしているなどの理由で auto モードがセッションで利用できない場合、この選択肢は Yes, auto-accept edits と表示されます。bypass permissions を有効にしてセッションを開始した場合は、代わりに Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session と表示されます。
• Yes, manually approve edits: 承認し、各編集を個別にレビューします。
• No, keep planning: plan モードにとどまり、変更してほしい内容を Claude に伝えます。

計画を承認すると plan モードが終了し、セッションは各承認の選択肢に記載された権限モードに切り替わり、Claude が編集を開始します。再度計画するには、Shift+Tab で plan モードに戻すか、次のプロンプトの先頭に /plan を付けます。

Ctrl+G を押すと、提案された計画をデフォルトのテキストエディタで開き、Claude が処理を進める前に直接編集できます。showClearContextOnPlanAccept が有効な場合、計画を承認して計画のコンテキストをクリアする選択肢がリストの先頭に追加されます。

計画を承認すると、すでにセッションに名前を付けていない限り、計画に基づいて生成されたタイトルもセッションに付けられます。

plan モードをデフォルトに設定する

プロジェクトのターミナルセッションで plan モードをデフォルトにするには、別の権限モードで開始するの例に示すように、.claude/settings.json で defaultMode を plan に設定します。VS Code 拡張機能が開始する会話は、開始時の権限モードについてプロジェクト設定を読み取りません。その場合は、代わりに VS Code のユーザー設定で claudeCode.initialPermissionMode を plan に設定してください。

auto モードで権限プロンプトを排除する

auto モードを使用すると、Claude は日常的な権限プロンプトなしで実行できます。別の分類器モデルが実行前にアクションをレビューし、リクエストの範囲を超えるもの、認識されていないインフラストラクチャを対象とするもの、または Claude が読んだ悪意のあるコンテンツによって駆動されているように見えるものをブロックします。明示的な ask ルールは引き続きプロンプトを強制します。

Claude Code v2.1.283 以降では、auto モードはすべてのプランとプロバイダーにおいて、インタラクティブなターミナルセッションと VS Code セッションの組み込みの開始権限モードです。それより前のバージョンでは、Pro、Max、Team プランでのみ組み込みの開始権限モードです。

分類器は、auto モードと plan モードで分類器がコマンドをレビューしている間の両方で、Claude が SendMessage を使用して別のエージェントに送信する各メッセージ（プレーンテキストか構造化されたエージェントチームメッセージかを問わず）も、Claude Code が配信する前にレビューします。送信のレビューには Claude Code v2.1.222 以降が必要です。

デフォルトでは、分類器は rm -rf / や rm -rf ~ など、認識された rm および rmdir によるクリティカルパスの削除をレビューしません。各権限モードでこれらがどのように扱われるかについては、クリティカルパスを参照してください。

auto モードはまた、Claude が確認のための質問で止まらずに作業を続けるよう促します。ただし、プロンプトやスキルが明示的にそれを前提としている場合は、Claude は引き続き質問します。引き続きプロンプトが表示されるモードでより強い自律的な動作を得るには、代わりに Proactive 出力スタイルを設定してください。

[!WARNING]

auto モードは権限プロンプトを減らしますが、安全性を保証するものではありません。全体的な方向性を信頼できるタスクに使用し、機密性の高い操作のレビューの代わりとしては使用しないでください。

auto モードは、アカウントが以下のすべての要件を満たす場合にのみ利用できます。

• プラン: すべてのプラン。
• 組織: Team と Enterprise では、auto モードはデフォルトで利用可能です。管理者は管理設定で permissions.disableAutoMode を "disable" に設定することで、組織の auto モードをオフにできます。
• モデル: Anthropic API と Claude Platform on AWS では、Claude Opus 4.6 以降、Sonnet 4.6 以降、Haiku 5.5、または Fable モデル。Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry、およびサインイン済みの Claude apps gateway セッションでは、Claude Sonnet 5 以降、Opus 4.7 以降、Haiku 5.5、および Fable モデルのみです。Sonnet 4.5、Opus 4.5、Haiku 4.5、claude-3 モデルを含む古いモデルは、どのプロバイダーでもサポートされていません。
• プロバイダー: Anthropic API、Claude Platform on AWS、Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry、およびサインイン済みの Claude apps gateway セッションでデフォルトで利用可能です。

Claude Code が auto モードを利用不可と報告する場合は、まずこれらの要件と、いずれかの設定ファイルが disableAutoMode を設定していないかを確認してください。また、Anthropic がサーバー側で auto モードをオフにしているか、サーバーがアカウントに対して auto モードを拒否した可能性もあります。いずれかの回答を受け取ったセッションは、セッションが終了するまで auto モードをオフのままにするため、後で新しいセッションを開始してください。

モデル名を示し、auto モードがアクションの「安全性を判断できない」と述べる別のメッセージは、分類器リクエストが失敗したことを意味します。この失敗は通常一時的なものですが、Amazon Bedrock では、アカウントがそのモデルを呼び出せるようになるまで繰り返される場合があります。原因と対処方法については、エラーリファレンスを参照してください。

設定で defaultMode: "auto" を設定したのに、ターミナルセッションがエラーなしで Manual モードで開始する場合、その設定は .claude/settings.json または .claude/settings.local.json にある可能性があります。auto はこれらのファイルからは有効になりません。~/.claude/settings.json に移動してください。VS Code 拡張機能が開始した会話の場合は、代わりに権限モードの切り替えにある拡張機能独自のリストを確認してください。

Bedrock、Agent Platform、または Foundry での auto モード

Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry、およびサインイン済みの Claude apps gateway セッションでは、auto モードはデフォルトで利用可能です。そこで権限モードを設定しない場合、インタラクティブなセッションは auto モードで開始し、claude -p や Agent SDK の実行は Manual モード（設定値は default）で開始します。

• インタラクティブなターミナルセッションと VS Code セッション: auto 以外の権限モードで開始するには、別の権限モードで開始するの説明に従って permissions.defaultMode を設定するか、VS Code 拡張機能のモードインジケーターから権限モードを選択します。これらのセッションを auto モードで開始する Claude Code のバージョンは、セッションがどのモードで開始するかに記載されています。
• claude -p と Agent SDK の実行: auto モードで開始するには、claude -p に --permission-mode auto を渡すか、TypeScript では permissionMode: "auto"、Python では permission_mode="auto" を渡します。権限モードを渡さない場合は、claude -p および Agent SDK の実行でツール呼び出しが拒否されるを参照してください。このセクションでは以前の Claude Code バージョンについても説明しています。

これらのプロバイダーでサポートされているのは、Claude Sonnet 5 以降、Opus 4.7 以降、Haiku 5.5、および Fable モデルのみです。その他のモデルでは、セッションは代わりに Manual で開始します。これらのプロバイダーで Haiku 5.5 を使用して auto モードを利用するには、Claude Code v2.1.293 以降が必要です。

開発者が auto モードを使用できないようにするには、管理設定で disableAutoMode を "disable" に設定します。これにより auto が Shift+Tab のサイクルから削除され、--permission-mode auto で開始されたセッションは代わりに Manual で開始します。すでに auto モードで実行中のセッションは、この設定が管理者がデプロイしたソースからそのセッションに届くと auto モードを終了し、auto mode disabled by settings と表示します。v2.1.251 より前では、実行中のセッションは終了するまで auto モードを維持していました。

サーバー側の分類器レビュー

auto モードでは、Claude Code は独自の分類器リクエストを送信する代わりに、セッションのモデルリクエストの一部として、決定順序がレビューに回すアクションをチェックするようサーバーに依頼できます。以下のセッションがサーバーに依頼します。

• Anthropic API への直接接続: インタラクティブなターミナルセッション、および -p、Agent SDK、VS Code 拡張機能、デスクトップアプリのセッションで、プランやアカウントの種類を問わず、Anthropic の段階的な展開に応じて。インタラクティブなターミナルセッションでは、Pro、Max、Team プランでは Claude Code v2.1.271 以降、Enterprise プランと Claude API アカウントでは v2.1.278 以降が必要です。-p、Agent SDK、VS Code 拡張機能、デスクトップアプリのセッションでは、Claude Code v2.1.281 以降が必要です。v2.1.282 以降、テレメトリをオフにしたなどの理由で機能フラグを取得しないセッションは、どの種類のセッションでもデフォルトでサーバーに依頼します。
• クラウドプロバイダー、または LLM ゲートウェイやプロキシ: Claude Platform on AWS、Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry で、また ANTHROPIC_BASE_URL を LLM ゲートウェイまたはプロキシに向けている場合は常に、プランを問わず。デフォルトで依頼するには Claude Code v2.1.278 以降が必要です。
• サインイン済みの Claude apps gateway セッション: Claude Code v2.1.280 以降が必要です
• Anthropic がホストする環境でのクラウドセッション: Web、モバイルアプリ、または Cloud を選択したデスクトップアプリから開始した場合、プランを問わず。クラウドのスケジュールタスクによって開始されたセッションは、Anthropic の段階的な展開に応じてサーバーに依頼します。

サーバーがアクションをレビューする場合、その判定によってアクションの扱いが決まります。それ以外に 2 つの結果があり得ます。

• サーバーがセッションをレビューしない: レスポンスがレビュー結果なしで完了するか、サーバーがこのセッションをレビューしないと応答します。最も一般的な原因は、レビューの依頼や結果を破棄する LLM ゲートウェイまたはプロキシと、まだサーバー側チェックに対応していないプラットフォーム、リージョン、または認証情報です。Claude Code は独自の分類器リクエストにフォールバックします。そのフォールバックがセッションの残りの期間にわたって維持されることになると、分類器リクエストが課金対象となるアカウントでは、分類器リクエストの料金に関する通知が表示されます。
• サーバーがアクションの判定を返さない: Claude Code は、レビューなしで実行するのではなく、アクションを拒否します。どの接続でも、レビュー結果が届く前にレスポンスが終了した場合や、結果が Claude Code の読み取れない形式で届いた場合に発生します。レスポンスを途中で切ったり結果を書き換えたりする LLM ゲートウェイやプロキシは、どちらの原因にもなり得ます。Anthropic API への直接接続では、タイムアウトなどでサーバーのチェックがそのアクションについて失敗した場合にも発生します。拒否メッセージ、拒否が繰り返された場合の動作、および対処方法については、サーバーが安全性の判定を返さなかったを参照してください。

サーバーへの依頼をスキップして常に Claude Code 独自の分類器リクエストを使用するには、CLAUDE_CODE_AUTO_MODE_SERVER=0 を設定します。Anthropic API への直接接続では、この変数には Claude Code v2.1.281 以降が必要です。そこで 1 に設定すると、CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 も設定していない限り、まだサーバーレビューが有効になっていないセッションでサーバーレビューがオンになります。CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 を設定して CLAUDE_CODE_AUTO_MODE_SERVER を未設定のままにすると、プレリリース機能を無効にするで説明されている場合を除き、Claude Code はサーバーへの依頼も停止します。

デフォルトの分類器モデル

デフォルトでは、分類器リクエストは Claude Sonnet 5 に送信されます。/status で Auto mode server が Enabled と表示されている場合、リクエストはサーバーのレビューの対象外の呼び出しに対してのみ送信されます。

この表で、セッションに一致する最初の行を見つけてください。Sonnet 5 の代わりに、その行のモデルが使用されます。

Sonnet 5 または ANTHROPIC_DEFAULT_SONNET_MODEL のモデルがプロバイダーから利用できない場合、または組織のモデルポリシーで除外されている場合、Claude Code はフォールバックモデルを使用します。これはセッションのモデルであり、Fable セッションでは Opus モデルです。

分類器モデルを選択する

Claude Code v2.1.302 以降では、CLAUDE_CODE_AUTO_MODE_MODEL を完全なモデル ID に設定すると、デフォルト以外のモデルで分類器を実行できます。クラウドプロバイダー独自の完全なモデル ID も使用できます。次の ~/.claude/settings.json の例では Claude Sonnet 4.6 を設定しています。

{
  "env": {
    "CLAUDE_CODE_AUTO_MODE_MODEL": "claude-sonnet-4-6"
  }
}

指定したモデルがレビューしない場合

複数の状況に該当する場合は、最初に記載されているものに従ってください。

分類器が使用したモデルを確認する

シェルから --debug-file を指定して auto モードのセッションを開始します。

claude --permission-mode auto --debug-file classifier-debug.log

Claude に読み取り専用ではないシェルコマンドを実行させてから、ログで classifier_request_started を検索します。

• model= の後に指定したモデルがある: 変数が有効になっています
• model= の後に別のモデルがある: ログで ignoring CLAUDE_CODE_AUTO_MODE_MODEL を検索します。理由と必要な手順が示されています
• 該当する行がない: Claude Code のプロンプトで /status の Auto mode server を確認します。
  • Enabled: サーバーがこのセッションの呼び出しをレビューするよう設定されています。
  • Disabled: 権限モードが auto であることを確認してから、Claude に読み取り専用ではない別のコマンドを実行させます。

分類器がデフォルトでブロックするもの

分類器は、作業ディレクトリと、セッション開始時にそのディレクトリに設定されていたリモートを信頼します。セッション中に git remote add や git remote set-url で追加または向け先を変更されたリモートは信頼されず、それ以外のものはすべて、信頼できるインフラストラクチャを設定するまで外部として扱われます。

デフォルトでブロック:

• curl | bash のようなコードのダウンロードと実行

• 外部エンドポイントへの機密データの送信

• 本番環境へのデプロイとマイグレーション

• クラウドストレージでの大量削除

• IAM またはリポジトリ権限の付与

• 共有インフラストラクチャの変更

• セッション前から存在していたファイルの不可逆的な破壊

• Force push

• 実行時にシークレットや機密データをリポジトリの外に送信する、またはデプロイが公開する範囲を広げる変更のコミットまたはプッシュ。これには、まだシークレットを受け取っていない宛先にシークレットを渡す CI ワークフローやデプロイ設定、シークレットストアを読み取ってデータを外部に送信するスクリプトやセットアップ手順、そしてレジストリ、可視性、アーティファクト、ソースマップの設定など、デプロイが公開する範囲を広げる設定変更が含まれます。このチェックはどのブランチにも適用され、リポジトリが公開されている場合でも適用され、そのコミットやプッシュがパイプラインをトリガーするかどうかにかかわらず、変更がコミットまたはプッシュされた時点で発動します。解除するには、コミットやプッシュだけでなく、実行時の影響を明示する必要があります

• git reset --hard、git checkout -- .、git restore .、git clean -fd、git stash drop、または git stash clear（分類器はコミットされていない変更を破棄するものと推定します）

• HEAD のコミットがこのセッションで作成されたものでない場合の git commit --amend

• v2.1.198 以降、HEAD のコミットがすでにプッシュされている場合の git commit --amend。メッセージのみの書き換えはブロックされません。これは、Claude がこのセッション中に作成したコミットに対し、新たにステージされたものがない状態で --amend -m を実行する場合です

• terraform destroy、pulumi destroy、cdk destroy、または terragrunt destroy、およびリソースを破棄するプランの適用

• シークレットマネージャーへの書き込み、または DNS レコードや TLS 証明書の変更

• 人間が承認していないプルリクエストのマージ、Claude 自身のプルリクエストの承認、または CI チェックの無効化

• atlantis apply やボットの /deploy、/merge など、それ自体が自動化へのコマンドとなるコメントの投稿

• 本番環境の機能フラグの切り替え、段階的な展開、または削除

• 保護された IaC スコープへのインフラストラクチャ変更の適用、またはクラスターノードのドレインと削除

• ラベルセレクターや他のユーザーのジョブまで対象にしてしまう --all など、指定したリソースを超えて及ぶ共有コンピュートクラスターへの書き込み

• DaemonSets や admission webhooks など、すべてのノードで実行される、またはクラスタートラフィックを傍受する Kubernetes リソースの作成

• 機密性の高いリモートターゲットへのインタラクティブシェルやポートフォワード

• ローカルサービスをパブリックインターネットから到達可能にするトンネルやリバースシェルの開設

• 有効な認証情報やトークンのトランスクリプトまたはファイルへの出力

• 環境で機密データの保存場所として記載されている場所へのアクセス、そこからのデータのコピー、またはエントリが除外している対象者へのそこからのデータ送信

• 内部パッケージレジストリを迂回してパブリックレジストリからパッケージをインストールすること。これは、内部レジストリやミラーが環境に記載されている場合、または会話の中で Claude にそれが存在すると伝えた場合に適用されます

• --insecure のような、安全ガードを無効にするフラグを付けたコマンドの実行

• --dangerously-skip-permissions や --no-sandbox で起動したものなど、人間の承認やサンドボックスなしで実行される自律エージェントループの起動。これには、--yes-always で起動したランナーなど、分離とアクションごとの承認を無効にしてサードパーティのエージェントや eval ハーネスを実行することも含まれます

• ページコンテンツ、Cookie、または認証情報をオリジン外に送信する可能性のある Claude in Chrome のブラウザアクション

• 特定の名前付きパスではなく、ワイルドカード、glob、または経過時間フィルターによって /tmp、$TMPDIR、またはその他の共有スクラッチディレクトリやキャッシュディレクトリ内のファイルを削除すること

• 他の人や共有システムに送信、アップロード、公開、または書き込まれるコンテンツに、ユーザー自身のメッセージがその受信者に対して認めていない機密性の高い詳細を含めること。リポジトリが信頼境界の外にあるか公開されている場合（組織自身の公開リポジトリを含む）、PR やイシューの本文、コミットメッセージ、コメントはこの種の外部向けコンテンツとして扱われます。内部のファイルパス、コードネーム、メールアドレスやアカウント識別子などの実際の API レスポンスデータ、インフラストラクチャ識別子は機密性の高い詳細として扱われます。メールアドレス、アカウントや組織の識別子、使用量の指標など、API レスポンスから得た実際の個人データを PR やイシューの本文に含める場合は、リポジトリの可視性や信頼境界にかかわらず、それらの詳細と受信者を明示する必要があります

• Claude Code 自身の tmux ペインにキーストロークを送信して自身のインターフェースを操作すること（分類器はこれを、Claude が自身の権限や監視を変更するものとして扱います）

• 認証、アクセス制御、入力検証、サンドボックス化などのセキュリティ動作を保護するテストやアサーションのコメントアウト、削除、または強制的な合格化

• より具体的な削除ルールが適用されず、ユーザーがそのリソースを指定していない場合に、セッション中に Claude が作成していないステートフルなリソースを削除または破棄すること

• API ベース URL、プロキシエンドポイント、webhook レシーバー、またはレジストリミラーを、タスクにそぐわないサードパーティホストに向け直すこと（.env.example のようなサンプルファイル内を含む）

• 新しいリモートをユーザーが指定していない限り、git remote set-url や git remote add でプッシュ先を変更すること

• 公開されていることがわかっているリポジトリへのシークレット、個人データ、または預かったデータのプッシュ、またはそのリポジトリ自体の作業に含まれない機密資料のプッシュ。dotfiles リポジトリ自体の対象となる内容は、個人データや預かったデータに関する唯一の例外であり、プライベートリポジトリのコンテンツがいずれかの公開サーフェスに到達する場合も同様にブロックされます。リポジトリの可視性が確認できない場合、分類器はそれだけを理由にブロックせず、代わりに他のルールに照らしてコンテンツを判断します

• 外部のターゲットをユーザーが指定していない限り、別のリポジトリや組織に対するプルリクエストの作成、gh repo fork によるフォーク、またはサードパーティリポジトリへのプッシュ

• ソースと宛先の両方をユーザーが指定していない限り、機密性の高いローカルストア、または名前、パス、種類から機密であるとわかるファイルのコンテンツを、コミット、プッシュ、PR やイシューのテキスト、gist やペースト、またはパッケージの公開に含めること。セッションのトランスクリプトと会話ログ、SSH キー、クラウドの認証情報、ブラウザプロファイル、シェル履歴などの認証情報や設定のドットフォルダ、ユーザーデータのエクスポートはすべて対象であり、リポジトリがプライベートであっても解除されません

• Claude Code のセッショントランスクリプト、つまり ~/.claude/projects/ または設定した config ディレクトリ配下の .jsonl 履歴ファイルへの書き込み（直接か、シェルコマンド経由かを問いません）。このルールは、Claude Code が独自のチェックのために各トランスクリプトエントリに追加するメタデータ行も対象とします。トランスクリプトの読み取りはブロックされません

• rm -rf "$VAR" や Remove-Item -Recurse -Force $dir のような再帰的な強制削除で、対象が分類器の見る会話のどこでも代入されていないシェル変数、またはそのような変数を起点とする glob であるもの。その値は分類器が受け取らない以前のコマンド出力からのみ得られたものであるため、分類器は削除対象を他の削除ルールに照らして検証できません。このブロックは、削除する正確なパスをユーザーが指定するか、Claude が解決済みのリテラルパスをコマンドに書き込んで削除を再実行すると解除されます。分類器が対象を解決できる削除は影響を受けません。

  rm -rf "$VAR"/* のように変数の直下にある glob は、代わりに重要なパスとして扱われます。Remove-Item の対象が単独の * であるか、/* または \* で終わる場合は分類器に到達せず、Claude Code がそれらを直ちに拒否します。

これらのカテゴリのいくつかは、機密性の高いリモートターゲットや保護された IaC スコープなど、具体的な名前に絞り込める環境エントリに依存しています。

Claude Code v2.1.257 以降では、以下もデフォルトでブロックされます。

• 169.254.169.254 などのクラウドインスタンスメタデータエンドポイントに認証情報を要求すること、またはマシン自身のサービスアカウントやノード ID を使ってクラウド、クラスター、レジストリへの呼び出しを明示的に認証すること
• トンネル、リバースシェル、外部を指すように書き換えたリゾルバーやプロキシの設定など、直接リクエスト以外の経路でパブリックホストに到達すること
• ノード証明書やノードのコンテナレジストリ認証など、タスクではなくホストに属する認証情報を読み取ること
• Claude が起動していない隣接するコンテナ、ポッド、VM、またはコンテナの下にあるノードへの接続やスキャン

Claude Code を実行する環境がこれらのいずれかを許可する前提である場合は、autoMode.environment の Host containment エントリでその構成を説明してください。

Claude Code v2.1.261 以降では、以下もデフォルトでブロックされます。

• URL 自体に共有するコンテンツが含まれている場合に、公開ペースト、図、またはデータ共有サービスへのリンクを、メッセージ、PR やイシューのテキスト、ドキュメント、その他リンクが開かれたり取得されたりする場所に投稿または書き込むこと（ユーザーがそのサービスを指定した場合を除く）

デフォルトで許可:

• 作業ディレクトリ内のローカルファイル操作

• ロックファイルやマニフェストで宣言された依存関係のインストール

• .env の読み取りと、対応する API への認証情報の送信

• 読み取り専用の HTTP リクエスト

• デフォルトブランチを含む、作業中のリポジトリの任意のブランチへのプッシュ。production や gh-pages など、名前からデプロイ先や公開先であるとわかるデフォルト以外のブランチは対象外で、分類器はそこへのプッシュを個別に判断します。

  プッシュの内容は引き続き分類器の他のルールに照らしてチェックされ、permissions.deny ルールはすべてのモードで引き続き記述されたとおりにプッシュコマンドをブロックできます。リモート側のブランチ保護も引き続き適用されます。

• 同じセッション内で Claude が以前に作成したジョブそのものの削除

• タスクの一環としての、セキュリティ関連のコード、設定、脅威モデルの読み取り、レビュー、または作成

• 同じマルチエージェントセッションで協働するエージェント間のメッセージ

• environment に記載した信頼できるドメイン、バケット、サービスへのデータ送信。これはデータの流れのみを対象とし、同じインフラストラクチャに対する破壊的な操作や認証情報の操作は対象外です

• 信頼できる内部ドメイン、localhost、またはユーザーが指定した URL への Claude in Chrome のナビゲーション

サンドボックス化されたコマンドは、デフォルトではネットワークアクセスを持ちません。Claude はコマンドに必要なホストをコマンド自体に明示し、分類器はそれらをコマンドと一緒にレビューし、承認されたリストによってそのコマンドに限りそれらのホストへのアクセスが開かれます。リストで開けるものと開けないもの、およびコマンドがリストにないホストにアクセスしようとした場合の動作については、コマンドごとの許可ドメインを参照してください。

claude auto-mode defaults を実行すると、完全なルールリストが JSON として出力されます。日常的なアクションがブロックされる場合、管理者は autoMode.environment 設定で信頼できるリポジトリ、バケット、サービスを追加できます。auto モードを設定するを参照してください。

作業中のリポジトリの任意のブランチへのプッシュと、リクエストに沿ったプルリクエストの作成は、シークレットや機密データがリポジトリの外に出る場合や、プルリクエストが別のリポジトリや組織を対象とする場合など、そのプッシュやプルリクエストがブロックリストに該当しない限り、プロンプトなしで実行されます。auto モードのまま、これらのコマンドの前に人間によるチェックポイントを設けるには、コマンドに記述されたとおりにマッチする permissions.ask ルールを追加します。一般的な境界を参照してください。

作業ディレクトリ外の最初の読み取り

permissions.blockReadsOutsideWorkingDirectories がオフの間、auto モードでは、ネットワークパスからの読み取り以外のファイルの読み取りは、作業ディレクトリ外の読み取りを含め、プロンプトなしで実行されます。Claude が作業ディレクトリ外のパスに対して Read、Grep、または Glob ツールを初めて使用するとき、Claude Code はその読み取りを許可するかどうかを尋ねます。

このプロンプトは、非インタラクティブな -p 実行やバックグラウンドセッションでは表示されず、そこでの読み取りは従来どおり実行されます。

どのように回答しても、Claude は作業を続けます。

• はい、今後も作業ディレクトリ外の読み取りを許可する: 読み取りが実行され、以降の作業ディレクトリ外の読み取りも従来どおり実行されます。Claude Code は回答を記録するため、このプロンプトは再び表示されません
• いいえ、今後は作業ディレクトリ外の読み取りをブロックする: 読み取りは拒否され、Claude Code はユーザー設定で permissions.blockReadsOutsideWorkingDirectories を true に設定します。これにより、以降のすべてのセッションとすべての権限モードで、ファイルツールはそのような読み取りを拒否します。後でそのようなパスを Claude が読み取れるようにするには、/add-dir でそのディレクトリを追加するか、この設定を削除します。
• いいえ、次回も確認する: 読み取りは拒否され、次に作業ディレクトリ外を読み取るときに再びプロンプトが表示されます
• はい、ただし次回も確認する: 読み取りが実行されますが何も保存されず、次に作業ディレクトリ外を読み取るときに再びプロンプトが表示されます

会話で伝えた境界

分類器は、会話で伝えた境界をブロックのシグナルとして扱います。Claude に「プッシュしないで」や「デプロイする前に私のレビューを待って」と伝えると、デフォルトのルールでは許可されるアクションであっても、分類器は該当するアクションをブロックします。境界は、後のメッセージで解除するまで有効です。条件が満たされたという Claude 自身の判断では解除されません。

境界はルールとして保存されません。分類器はチェックのたびにトランスクリプトから境界を読み直すため、コンテキスト圧縮によって境界を伝えたメッセージが削除されると、境界が失われる可能性があります。確実な保証が必要な場合は、代わりに deny ルールを追加してください。

会話で伝えた承認

ブロックされたアクションを許可すると Claude に伝えると、分類器はそれをユーザーの承認と解釈し、ブロックを解除できます。伝え方によって、アクションが実行されるかどうかと、承認がどこまで及ぶかが決まります。

• アクションとその詳細を明示する: メッセージでは、アクションと、force push の対象ブランチなど、それを危険にしている具体的な要素を明示する必要があります。動詞だけを示しても何も解除されないため、「force-push してもいいよ」ではブロックは残ります。
• 1 つのアクションにのみ適用されると考える: 承認は明示した破壊的アクションに適用されるため、継続的な承認として与えない限り、後のアクションは再びブロックされます。日常的なパターンを 1 つずつ承認するのをやめるには、autoMode.allow に追加してください。
• 一部のブロックは解除されない: 分類器の優先順位に、承認で解除できるブロックが定められています。承認で解除されない手順を実行するには、auto モードを終了して権限プロンプトに回答してください。

auto モードがフォールバックするとき

auto モードがセッションのアクションを承認できない場合、その後の動作はケースによって異なります。

• アクションがブロックされた場合: Claude Code は通知を表示し、そのアクションを /permissions の Recently denied タブに表示します。そこで r を押すと、手動承認で再試行できます。
• ブロックが繰り返された場合: 分類器がアクションを 3 回連続、または合計 20 回ブロックすると、auto モードは一時停止し、Claude Code はプロンプトの表示を再開します。プロンプトで示されたアクションを承認すると auto モードが再開します。ブロックの数え方については、繰り返しブロックのしきい値を参照してください。
• 分類器から判定が得られない場合: auto モードとは別の安全チェックが分類器自体のリクエストを拒否した場合、または分類器の応答を解析できない場合、Claude Code は通知も Recently denied のエントリもなしにアクションを拒否します。各ケースで表示されるメッセージと対処方法については、auto モードがアクションの安全性を判断できないを参照してください。
• サーバーから判定が得られない場合: サーバー側の分類器レビューでは、Claude Code はサーバーが判定を返さないアクションを拒否し、判定のないレスポンスが 10 回連続するとターンを停止します。サーバーが安全性の判定を返さなかったを参照してください。
• チェック中にモードを切り替えた場合: 分類器のチェックが保留中に権限モードを切り替えると、Claude Code は新しいモードでは要求されなかったはずの判定を破棄します。代わりに承認を求めるプロンプトが表示されるか、dontAsk モードではアクションが自動的に拒否されます。

繰り返しブロックのしきい値

3 回連続および合計 20 回というブロックのしきい値は設定できません。合計カウンターはセッションの間保持され、それ自体の上限によってフォールバックが発生したときにのみリセットされます。auto モードとは別の安全チェックが分類器自体のリクエストを拒否した場合、Claude Code はその拒否をどちらのしきい値にもカウントしません。

--permission-prompt-tool を指定していない非インタラクティブな -p 実行には、フォールバック先のプロンプトがありません。繰り返しのブロックがしきい値に達すると、そのアクションは実行されず、Claude は作業を続けます。Claude Code は実行を停止しません。

ブロックが繰り返される場合、通常は分類器がインフラストラクチャに関するコンテキストを欠いていることを意味します。/feedback を使用して誤検知を報告するか、管理者に信頼できるインフラストラクチャを設定してもらってください。

auto モードがアクションを評価する方法

以下のセクションでは、Claude Code がアクションを評価する順序、分類器がサブエージェントの作業をレビューする方法、および分類器の呼び出しによって追加されるコストとレイテンシーについて説明します。

分類器がアクションを評価する方法

各アクションは決まった決定順序で処理され、最初に該当したステップが適用されます。

1. 許可、確認、または拒否ルールに一致するアクションは即座に解決されます。ただし、次の例外があります。
   • 保護されたパスへの書き込みは、許可ルールに一致する場合でも分類器に回されます。保護されたパスが、シンボリックリンクされた設定ファイルの指す先のファイルである場合は、保護されたパスの一覧に記載されているとおり、代わりに書き込みの際にプロンプトが表示されることがあります
   • 認識された rm および rmdir による重要なパスの削除は、どの許可ルールでも承認されません
   • requiresUserInteraction が指定された MCP ツールは、許可ルールに一致する場合でも直接プロンプトを表示します。組織が ask に設定したコネクタツールも、その設定が Claude Code に適用されるセッションでは同様です
   • コマンドごとの許可ドメインを伴うシェルコマンドも、許可ルールに一致する場合でも分類器に回されます。ルールが承認するのはコマンドであり、そのホストではないためです
   • Bash(git push *) のようにコマンドの内容に一致する確認ルールは、権限プロンプトにフォールバックします
   • シンボリックリンクのチェックによって保護されたパスに解決される書き込みは、Claude が要求したパス自体が保護されていない場合にプロンプトを表示します
   • ネットワークパスからの読み取りは、許可ルールに一致する場合でもプロンプトを表示します
2. 読み取り専用のアクションと作業ディレクトリ内のファイル編集は自動承認されます。ただし、保護されたパスへの書き込みと、プロンプトが表示される作業ディレクトリ外での最初の読み取りは除きます
   • サーバー側の分類器レビューがあるセッションでは、読み取り専用のシェルコマンドとサンドボックス化されたシェルコマンドはそのレビューを待ち、レビューで警告された場合はブロックされます
   • 作業ディレクトリ内への書き込みのうち、シンボリックリンクのチェックによって作業ディレクトリ外の場所に解決されるものはプロンプトを表示します
   • Claude が他のユーザーが作成したアーティファクトを読み取る場合は、そのセクションに記載されている承認のケースが適用されます
   • ネットワークパスからの読み取りはプロンプトを表示します
3. それ以外はすべて分類器に回されます。ただし、デフォルトの処理下にある重要なパスの削除は除きます。ステップ 1 で直接プロンプトを表示するコネクタツールと requiresUserInteraction の MCP ツールも分類器には到達しないため、組織が必須とする承認も同意のステップも自動承認されることはありません
4. 分類器がブロックした場合、Claude はその理由を受け取ります。ほとんどのセッションでは、理由は文章による説明ではなく、[Data Exfiltration] のように分類器が一致したルールの名前で示されます。拒否の確認を参照してください

インストールした mod が tool.check を処理する場合、その mod もアクションを承認できます。その承認がルールやフックを通過しないケースについては、フックで権限を拡張するを参照してください。

VS Code 拡張機能で Claude in Chrome のブラウザアクションがどのように承認されるかについては、VS Code セッションでの権限プロンプトを参照してください。

auto モードに入ると、任意のコード実行を許可する広範な allow ルールは除外されます。

• 包括的な Bash(*) または PowerShell(*)
• Bash(python*) のようなワイルドカード付きのインタープリター
• パッケージマネージャーの run コマンド
• Agent の allow ルール
• Monitor の allow ルール（Claude Code は Monitor のコマンドをシェル経由で実行するため）

Bash(npm test) のような限定的なルールは引き続き有効です。Claude Code は auto モードを終了すると、除外したルールを復元します。v2.1.236 より前では、Claude Code は auto モードで Monitor の allow ルールを有効なままにしていたため、ツール全体に一致するルールが分類器のレビューなしで Monitor のコマンドを承認していました。

また、Claude Code は git reset --hard や rm -rf など、コミットされていない作業を破棄する可能性のあるコマンドの前に自ら git status を実行し、ステージ済み、変更済み、または未追跡の作業があるかどうかを分類器に示します。リポジトリの git 設定で status.showUntrackedFiles=no が設定されている場合でも、Claude Code はこのチェックで未追跡のファイルを報告します。

Claude Code 自体が送信する分類器リクエストでは、分類器はユーザーメッセージ、ファイルの読み取りや検索などの読み取り専用の参照以外のツール呼び出し、および CLAUDE.md の内容を確認します。ツールの結果はこれらのリクエストから除去されるため、ファイルやウェブページ内の悪意のあるコンテンツが分類器を直接操作することはできません。

PostToolUse フックの classifierContext フィールドを使って呼び出しの結果に注釈を付けることができ、分類器はこれをアプリケーションが提供するコンテキストとして読み取ります。このフィールドには Claude Code v2.1.236 以降が必要です。

別のサーバー側プローブが受信したツールの結果をスキャンし、Claude が読む前に疑わしいコンテンツを指摘します。これらの層がどのように連携するかの詳細については、auto モードの発表とエンジニアリングの詳細解説を参照してください。

auto モードがサブエージェントを扱う方法

分類器はサブエージェントの作業を 3 つの時点でチェックします。

1. サブエージェントが開始する前に、委任されたタスクの説明が評価されるため、危険に見えるタスクは生成時にブロックされます。
2. サブエージェントの実行中、その各アクションは親セッションと同じ決定順序で、同じブロックルールと allow ルールに基づいて処理されます。サブエージェントのフロントマターにある permissionMode は無視されます。
3. サブエージェントが終了すると、親がレポートを読む前に、分類器がその作業と最終レポートをレビューします。分類器がサブエージェントの作業やレポートを指摘した場合、または別の API 安全チェックがレビューを拒否した場合でも、レポートはセキュリティ警告を先頭に付けて配信されます。分類器がレビューに利用できない場合、レポートには、行動する前にサブエージェントの作業を検証するよう促すメモが付いて届きます。

コストとレイテンシー

Claude Code の分類器リクエストは、/model での選択とは異なるモデルで実行される場合があります。どのモデルで実行されるかを参照してください。

Enterprise プラン、および Claude API、Claude Platform on AWS、Amazon Bedrock、Google Cloud の Agent Platform、または Microsoft Foundry を使用するアカウントでは、分類器の呼び出しはトークン使用量にカウントされます。各チェックではトランスクリプトの一部と保留中のアクションが送信され、実行前に往復の通信が 1 回加わります。読み取りと、保護されたパス以外での作業ディレクトリ内の編集は分類器をスキップするため、オーバーヘッドは主にシェルコマンドとネットワーク操作から生じます。サーバーがセッションのモデルリクエストの一部としてアクションをレビューする場合は、カウントされる個別の分類器呼び出しはありません。サーバー側の分類器レビューを参照してください。

サンドボックス化されたネットワークアクセスによって、接続ごとの分類器リクエストが追加されることはありません。分類器はコマンドが明示するホストをコマンドと一緒に 1 回のレビューで判断し、Claude Code は分類器を再度呼び出すことなく、各接続を承認済みのリストと照合します。

dontAsk モードで事前承認済みツールのみを許可する

dontAsk モードを設定すると、Claude Code は本来プロンプトを表示するすべてのツール呼び出しを自動的に拒否します。ただし、インストールした mod は、それらの呼び出しの一部を引き続き承認できます。mod が承認できる呼び出しを確認するには、フックで権限を拡張するを参照してください。

Claude は、Manual モードで承認が不要なアクション（作業ディレクトリ内のファイル読み取りや読み取り専用 Bash コマンドなど）を引き続き実行します。permissions.allow ルールに一致するアクションや、PreToolUse フックによって承認された呼び出しも実行されます。このモードは、Claude が実行できる内容を事前に定義しておく CI パイプラインや制限された環境で使用します。セッションが入力を待つことはありません。このモードでは、ステータスバーに ⏵⏵ don't ask on が表示されます。

Claude Code は、プロンプトを表示する代わりに、明示的なask ルールに一致するコールを拒否します。また、allow ルールが一致する場合でも組み込みの AskUserQuestion ツールを拒否し、その設定が Claude Code に到達するセッションで組織が ask に設定したコネクタツールについても同じことを行います。_meta["anthropic/requiresUserInteraction"]でマークされた MCP ツールも同じ方法で拒否します。これは、承認カードがこのモードが収集しない回答を必要とするためです。

次のものは、許可ルールや PreToolUse フックでは承認できません：

• 認識された rm および rmdir による重要なパスの削除（rm -rf / や rm -rf ~ など）
• ネットワークパスからの読み取り

クラウドセッションは defaultMode: "dontAsk" を無視します。詳細はbypassPermissionsを参照してください。

スタートアップ時にフラグで設定します：

claude --permission-mode dontAsk

bypassPermissions モードですべてのチェックをスキップする

bypassPermissions モードは権限プロンプトとセーフティチェックを無効にするため、保護されたパスへの書き込みを含むツール呼び出しが即座に実行されます。

bypassPermissions モードでも、どのモードでも自動承認されないアクションはそれぞれ、プロンプトが表示されるか拒否されます。ただし、危険な rm コマンドに対するプロンプトはオフにできます。別の組織の公開アーティファクトを読み取るにはユーザーの承認が必要ですが、このモードでは承認を求めないため、Claude はそれを読み取れません。PowerShell の Remove-Item の拒否もこのモードで適用されます。

このモードでは、および権限バイパスが利用可能なインタラクティブターミナルプランモードセッションでは、2 つのクロスセッションメッセージングセーフガードが引き続き適用されます。

• このマシンを超えたセッションへのメッセージに対する isolatePeerMachines 承認プロンプトが引き続き表示されます。
• crossSessionInbound 値が適用されない場合、Claude Code は別のセッションからのインバウンドメッセージを承認待ちで保持し、送信セッションが権限プロンプトもバイパスしていることを識別した場合にのみ確認なしで配信します。権限モードを終了してメッセージが保持されている場合、Claude Code はインバウンドルールを再適用し、保持されているメッセージのうち現在受け入れるものを配信します。

権限バイパスが利用可能な対話ターミナルセッションでは、Claude Code は plan モードのブロックも強制しません。Claude は引き続き編集せずに計画するよう指示されていますが、計画中に試みるファイル編集またはシェルコマンドはプロンプトなしで実行されます。明示的な ask ルールと、認識された rm および rmdir によるクリティカルパスの削除は引き続きプロンプトが表示されます。

プランモードは Claude Code がインタラクティブターミナルなしで実行される場所ではブロックを保持します。これには -p を使用した非インタラクティブ実行、Agent SDK セッション、および VS Code 拡張機能のチャットパネルでの会話が含まれます。そこでは、--allow-dangerously-skip-permissions により bypassPermissions が後で選択可能になります。

[!WARNING]

このモードはコンテナ、VM、またはインターネットアクセスのない dev コンテナなどの隔離された環境でのみ使用してください。そのような環境では Claude Code がホストシステムに損害を与えることができません。

このモードを有効にせずに開始したセッションから bypassPermissions に入ることはできません。permissions.defaultMode: "bypassPermissions" で起動時に有効にするか、有効化フラグを使用して有効にしてください。

claude --permission-mode bypassPermissions

--dangerously-skip-permissions フラグは同等です。

Claude Code は --restricted で開始したセッションで bypassPermissions を拒否します。--restricted には Claude Code v2.1.248 以降が必要です。

このモードを有効にして対話セッションを初めて開始すると、Claude Code は権限チェックなしで実行されたアクションの責任を受け入れるよう求める警告ダイアログを表示します。

• 受け入れた場合: Claude Code は skipDangerousModePermissionPrompt を ~/.claude/settings.json の true に設定するため、後のセッションではダイアログをスキップします。ダイアログを再度表示するには、そのファイルからキーを削除するか、false に設定してください。skipDangerousModePermissionPrompt リファレンスには、ユーザーまたは組織が設定できる他の設定ファイルが記載されています。
• 拒否した場合: Claude Code は終了します。

非対話モードではダイアログは表示されません。

バックグラウンドセッションは、ユーザー設定または管理設定に受け入れが記録されている場合、その受け入れを尊重します。

• 受け入れが記録されていない場合、claude --bg --permission-mode bypassPermissions は拒否されます。まず対話セッションでダイアログを受け入れてください。

• skipDangerousModePermissionPrompt が .claude/settings.local.json でのみ設定されている場合、バックグラウンドセッションはバイパスのリクエストを無視した状態で開始します。

  • --allow-dangerously-skip-permissions が無視された場合、bypassPermissions は Shift+Tab のサイクルから除外されます。
  • --permission-mode bypassPermissions または --dangerously-skip-permissions が無視された場合、セッションは代わりに Manual モードで開始されます。

  "skipDangerousModePermissionPrompt": true を ~/.claude/settings.json に追加してから、新しいバックグラウンドセッションを開始してください。

Linux と macOS では、Claude Code は root として、または sudo の下で実行されている場合、bypassPermissions モードでの起動を拒否します。

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

チェックは認識されたサンドボックス内では自動的にスキップされます。コンテナで自律的に実行するには、dev コンテナ設定を使用してください。これは Claude Code を非 root ユーザーとして実行します。

クラウドセッション は設定ファイルから defaultMode: "bypassPermissions" または "dontAsk" を尊重しないため、リポジトリのチェックイン設定はクラウドセッションをバイパス権限モードで開始できません。設定はサイレントに無視され、セッションはモードドロップダウンに表示される権限モードで開始されます。権限モードを切り替えるを参照して、クラウドセッションが提供するモードを確認してください。

[!WARNING]

bypassPermissions はプロンプトインジェクションまたは意図しないアクションに対する保護を提供しません。権限プロンプトがはるかに少ないバックグラウンドセーフティチェックの場合は、代わりにオートモードを使用してください。管理者は 管理設定で permissions.disableBypassPermissionsMode を "disable" に設定することでこのモードをブロックできます。

バックグラウンドセッションで権限バイパスが無視される

この通知は、バックグラウンドセッションがユーザー設定または管理設定で権限バイパスの警告の受け入れを見つけられなかったため、起動時に行われたバイパスのリクエストを無視したことを意味します。

Bypass permissions was requested at launch and ignored · if that was you, ~/.claude/settings.json needs "skipDangerousModePermissionPrompt": true

"skipDangerousModePermissionPrompt": true を ~/.claude/settings.json に追加してから、新しいバックグラウンドセッションを開始してください。

claude agents が対話セッションではスキップされる権限バイパスの警告を表示する

対話セッションではスキップされるのに claude agents が権限バイパスの警告を表示する場合は、skipDangerousModePermissionPrompt が .claude/settings.local.json または --settings ファイルで設定されていないか確認してください。対話セッションはそこにあるキーを警告の受け入れとみなしますが、claude agents はそうみなしません。そこで見つかったかどうかにかかわらず、警告を受け入れて、claude agents が参照する ~/.claude/settings.json にキーを追加してください。

保護されたパス

パスの小さなセットへの書き込みは、bypassPermissions モードおよび bypass permissions が利用可能なプラン モードのインタラクティブターミナルセッションを除き、自動承認されることはありません。これはリポジトリ状態と Claude 独自の設定の偶発的な破損を防ぎます。

--restrictedで開始されたセッションでは、Claude Code v2.1.248 以降が必要で、分類器は保護されたパスへの書き込みを承認できません。

保護されたパスへの書き込みを分類器にルーティングするモードでは、symlink チェックが保護されたパスに解決される書き込みは、Claude が要求したパス自体が保護されていない場合、代わりにプロンプトを表示します。

設定ファイルの permissions.allow ルールは、保護されたパスへの書き込みを事前承認しません。安全性チェックは Claude Code が設定から allow ルールを評価する前に実行されるため、~/.claude/settings.json または .claude/settings.json の Edit(.claude/**) などのエントリは、上記の表のモード別の結果を変更しません。プロンプトを表示するモードでは、プロジェクトの .claude/ フォルダまたは ~/.claude/ への書き込みのプロンプトで、以下のセッション スコープ オプションのいずれかを提供できます。

• プロジェクトの .claude/ フォルダの場合：Yes, and allow Claude to edit files in this project's .claude folder for this session
• ~/.claude/ の場合：Yes, and allow Claude to edit files in its ~/.claude folder for this session

保護されたディレクトリ：

• .git
• .config/git
• .vscode
• .idea
• .husky
• .cargo
• .devcontainer
• .yarn
• .mvn
• .claude。ただし、次のようないくつかの例外があります：
  • .claude/worktrees/ 配下にある Claude 自身の git worktree
  • ~/.claude/plans/、または設定した plansDirectory 内にある、現在のセッション自身のプランファイル
  • ~/.claude/jobs/<id>/tmp/ にあるバックグラウンドセッション自身のスクラッチディレクトリ
  • --restricted なしで開始されたセッションにおける、~/.claude/projects/<project>/memory/ などのプロジェクトの自動メモリディレクトリ内の markdown ファイル
  • --restricted なしで開始されたセッションにおける、.claude/agent-memory/ などのサブエージェントメモリディレクトリ内の markdown ファイル
• --plugin-dir で読み込んだディレクトリ。ファイルが変更されると、Claude Code がそこから mod のコードを再読み込みして実行するためです
• ~/.claude/dev-mods/、または CLAUDE_CONFIG_DIR が指すディレクトリ内の dev-mods/。Claude がユーザーのために作成した mod を保存する場所です

保護されたファイル：

• .gitconfig、.gitmodules
• .bashrc、.bash_profile、.bash_login、.bash_aliases、.bash_logout、.zshrc、.zprofile、.zshenv、.zlogin、.zlogout、.profile、.envrc
• .npmrc、.yarnrc、.yarnrc.yml、.pnp.cjs、.pnp.loader.mjs、.pnpmfile.cjs、bunfig.toml、.bunfig.toml
• .bazelrc、.bazelversion、.bazeliskrc
• .pre-commit-config.yaml、lefthook.yml、lefthook.yaml、.lefthook.yml、.lefthook.yaml
• gradle-wrapper.properties、maven-wrapper.properties
• .devcontainer.json
• .ripgreprc、pyrightconfig.json
• .mcp.json、.claude.json
• セッション開始時に --settings、--mcp-config、または --agents に渡したファイル
• ユーザー、プロジェクト、またはローカルの設定ファイル自体がシンボリックリンクである場合に、その設定ファイルが指し示すファイル（たとえば dotfiles リポジトリ内のファイル）。保護されたパスへの書き込みを分類器にルーティングするモードでは、このファイルへの書き込みは、許可ルールに一致する場合でも、代わりにプロンプトを表示します。このファイル自体のパスが別のフォルダの .claude/settings.json など設定ファイルのパスでもある場合、その書き込みは他の保護されたパスへの書き込みと同様に分類器に送られます

重要なパス

重要なパスは、Claude Code が rm および rmdir コマンドから保護するディレクトリです。ファイルシステムのルート、ホームディレクトリ、作業ディレクトリなどが含まれます。Claude Code はこれらのコマンドを実行前にチェックし、ターゲットが重要なパスであると認識したコマンドは、どの許可ルールでも承認されません。このチェックは一部のコマンドを見逃す可能性があるため、サンドボックス化などのオペレーティングシステムによる制御に代わるものではありません。

重要なパスの削除とは、Claude Code がターゲットを重要なパスとして認識する rm または rmdir コマンドのことです。"allow" を返す PreToolUse フックでもこれは承認されません。他のプロンプトをスキップする権限モードであっても、許可ルールや PreToolUse フックはこれを承認できません。

[!WARNING]

チェックで見逃されたコマンドは特別な処理を受けないため、セッション内で Bash コマンドを承認するものであれば何でも、プロンプトなしでそのコマンドを承認できます。これには、許可ルール、bypassPermissions モード、サンドボックスの自動許可モードが含まれます。チェックは rm と rmdir に適用されるため、承認された他のコマンドによっても重要なパスが削除される可能性があります。

以下の制御は、チェックがコマンドを認識するかどうかにかかわらず適用されます。

• 拒否ルール: コマンドにマッチする拒否ルールはそのコマンドをブロックします。ただし、インストールした mod は引き続きそれらの呼び出しの一部を承認できます
• サンドボックス化: サンドボックス化では、Bash コマンドが書き込めるパスをオペレーティングシステムが制限します。サンドボックス化されたコマンドでも作業ディレクトリは削除できます
• 厳格なサンドボックスモード: デフォルトでは、サンドボックス化されたコマンドはサンドボックス外で再試行でき、許可ルールや bypassPermissions モードはその再試行をプロンプトなしで承認できます。厳格なサンドボックスモードは再試行をオフにします

Claude Code が認識した削除がどうなるかは、権限モードによって異なります。Remove-Item と cmd 削除ビルトインには独自のチェックがあり、PowerShell の Remove-Item で説明されています。

どのパスが重要なのか

Claude Code は、rm または rmdir ターゲットが以下のいずれかである場合、重要なパスとして扱います。

• ファイルシステムのルート
• トップレベルディレクトリ、つまりルートの直接の子である /usr、/etc、/data などのディレクトリ
• ホームディレクトリ。Windows では、C:\Users\LONGNA~1 のような 8.3 形式の短い名前も含まれます
• Windows ドライブルートとそのトップレベルディレクトリ（C:\ や C:\Windows など）。\\?\C:\ や \\localhost\C$ のような表記も C:\ として扱われます
• 作業ディレクトリとその親
• 追加の作業ディレクトリとその親。ただし、削除が rm -rf <dir>/* のようにそれらの下のグロブである場合のみ。ディレクトリ自体に対する rm -rf <dir> はこのチェックをトリガーしません

/mnt/c や /Volumes/USB などのマウントされたドライブのパスについては、マウントされたドライブのプロンプトを参照してください。

ホームディレクトリの 8.3 形式の短い名前、および \\?\C:\ と \\localhost\C$ の表記に対するチェックには Claude Code v2.1.292 以降が必要です。

重要なパスとしてカウントされるその他のターゲット

Claude Code は、以下の rm および rmdir ターゲットも重要なパスとして扱います。最後の列は、各ターゲットがカウントされる理由を説明しています。

コマンド置換の出力のみであるターゲットのチェックをオフにするには、Claude Code を起動する環境で CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1 を設定します。

ネストされたコマンドとインラインスクリプト内の削除

Claude Code はこれらの構造内も確認します。

• ネストされたコマンド: (...) を使用したサブシェル、{ ...; } を使用したブレースグループ、$(...) またはバッククォートを使用したコマンド置換、または <(...) を使用したプロセス置換。Claude Code は、(rm -rf ~) や echo "$(rm -rf ~)" のように置換内にある重要なパスの削除、または同じコマンド内の他の場所にある削除を見つけます。
• インラインスクリプト: bash -c 'rm -rf ~' のように、-c を付けて sh、bash、zsh、または同様の POSIX シェルに渡されるスクリプト。
  • スクリプトがダブルクォートで囲まれている場合、呼び出し元のシェルはスクリプトの変数を展開してから、内部シェルがスクリプトを受け取ります。find . -name '*.tmp' -exec sh -c "rm -rf \"$1\"/*" _ {} \; では、コマンドはマッチごとに 1 回ファイルシステムルートからの削除に展開され、Claude Code はこれを重要なパスの削除として扱います。
  • sh -c 'rm -rf "$1"/*' _ {} のように $1 を実際の値にバインドするシングルクォートスクリプトは警告されません。

~ など、-c スクリプト内に直接書かれた重要なパスに対するチェックをオフにするには、Claude Code を起動する環境で CLAUDE_CODE_DISABLE_INLINE_SHELL_RM_PROMPT=1 を設定します。

フラグが付いたコマンドを書き直す

コマンドをチェックに合格するように書き直す方法は、使用しているその他のターゲットによって異なります。

• $DIR などの変数の下のグロブまたは末尾のスラッシュ: 各展開をガードして、変数が設定されていないか空の場合にシェルがエラーで停止するようにします。例えば rm -rf "${DIR:?}"/* のように、またはリテラルパスを使用します。すべての展開がこのようにガードされている削除はこのチェックに合格するため、bypassPermissions モードではプロンプトなしで実行されます。別の重要なパスチェックがそれにフラグを付けない限り。
• $HOME などの通常設定されている変数の下のグロブまたは末尾のスラッシュ: リテラルパスを使用します。
• ディレクトリ出力置換から割り当てられた変数: リテラルパスを使用します。"${D:?}" ガードはこのチェックをクリアしません。変数は空ではないためです。
• コマンド置換の出力のみであるターゲット: 置換を単独で実行してから、それが出力するリテラルパスを削除します。プロンプトは Claude に同じことを行うよう指示します。

変数の下のグロブまたは末尾のスラッシュの場合、プロンプトはフラグが付いた rm に名前を付け、チェックに合格するように書き直す方法を説明します。

Dangerous rm operation not ruled out プロンプト

理由の全文は次のとおりです。

Dangerous rm operation not ruled out — the shell may read this command differently than it was parsed

この理由は、シェルが Claude Code とは異なる方法でコマンドを解釈する可能性があることを意味します。そのため、rm が含まれていなくても、チェックされていない部分に削除が含まれている可能性があります。auto または bypassPermissions モードでは、次の文を含む拒否も同じチェックによるものです。

This command could not be checked for dangerous rm operations: the shell may read it differently than it was parsed.

bypassPermissions を含め、権限モードに応じて重要なパスの削除と同じプロンプトまたは拒否が発生します。ただし、bypassPermissions モードではそのプロンプトをオフにすることができます。このコマンドは、Bash または Bash(*) の許可ルール、サンドボックスの自動許可モード、"allow" を返す PreToolUse フックでは承認できません。コマンドを読んでからプロンプトを承認するか、拒否された場合はシェルで実行してください。

マウントされたドライブのプロンプト

マウントされたドライブのプロンプトは、macOS、Linux、WSL で、再帰的な rm が /mnt/c や /Volumes/USB/build など、一覧に記載されたマウントされたドライブのパスをターゲットにしている場合に表示されます。その理由には Dangerous rm operation on mounted drive path: <path> と表示されます。Claude Code は rm /Volumes/USB/build/* を /Volumes/USB/build の削除として読み取るため、/* ターゲットは再帰フラグがなくてもプロンプトが表示されます。

rm の許可ルールがあっても、Claude Code はこのコマンドを重要なパスの削除として処理し、権限モードに応じてプロンプトを表示するか拒否します。プロンプトを承認して rm を実行させるか、プロンプトをオフにします。

マウントされたドライブのプロンプトが表示されるパス

再帰的な rm または /* による削除のターゲットを、以下のパス形式と照合してください。<drive> や <name> などの各プレースホルダーは、ちょうど 1 つのパスセグメントを表します。

/Volumes、/media、/mnt 自体に対する再帰的または非再帰的な rm の場合は、代わりに重要なパスの理由 Dangerous rm operation on critical path: <path> が表示されます。

相対パスのターゲットは作業ディレクトリを基準とするため、/Volumes/USB で作業中に rm -rf build を実行すると /Volumes/USB/build がターゲットになり、プロンプトが表示されます。

マウントされたドライブのプロンプトをオフにする

他の原因によるプロンプトは残したまま、マウントされたドライブのプロンプトが表示されないようにするには、環境に CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1 を設定して Claude Code を起動します。例えば、シェルで変数を設定し、そこから claude を起動します。

export CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1
claude

この方法で起動したセッションでは、/Volumes/USB のようなドライブ全体と、その他の一覧に記載されたパスで、マウントされたドライブのプロンプトが表示されなくなります。Bash(rm *) を許可し、Manual モードを使用して /Volumes/USB で作業している場合、rm -rf build はプロンプトなしで実行されます。

それでも Dangerous rm operation on mounted drive path と表示されるプロンプトは、変数がセッションに届いていないことを意味します。

• 設定ファイル内の変数: Claude Code は、設定ファイルの種類にかかわらず、設定ファイルの env ブロック内の変数を無視するため、代わりに claude を起動する場所で変数を設定します
• 変数なしで起動されたセッション: 実行中のセッションは変数を取り込まないため、変数が設定された環境から claude を再度起動します

マウントされたドライブのプロンプトをオフにしてもプロンプトが表示される削除

rm の許可ルールがある Manual モードでは、マウントされたドライブのパスに対する rm で、Dangerous rm operation on mounted drive path という理由なしにプロンプトが表示されることがあります。

• 作業ディレクトリ外のターゲット: /Volumes/USB/project で作業中に rm -rf /Volumes/USB/other を実行するとプロンプトが表示されます。このプロンプトを止めるには、ターゲットを含むディレクトリをセッションに追加します
• * を含むターゲット: rm -rf build/* ではプロンプトが表示されます。そのプロンプトを承認してコマンドを実行するか、* を使わずに各ターゲットを指定するよう Claude に依頼します
• 重要なパスであるターゲット: /mnt 自体と作業ディレクトリ自体は重要なパスのままなので、どちらに対する rm -rf でもプロンプトが表示されます。そのプロンプトを承認して rm を実行させます

各権限モードでの重要なパスの削除

Claude Code が重要なパスの削除に対して行うことは、権限モードによって異なります。

明示的な ask ルール がコマンドにマッチする場合、Claude Code は auto モードでも承認を求めます。時間制限はありません。承認を求めるモードでは、PermissionRequest フック はプロンプトに答えることができます。

bypassPermissions モードでこれらの削除をプロンプトなしで実行するには、重要なパスの削除のプロンプトをオフにするを参照してください。

auto および bypassPermissions モードでの時間制限と拒否

auto および bypassPermissions モードでは、重要なパスの削除に対するターミナルプロンプトに 2 分間のカウントダウンが表示されます。

• カウントダウンが終了する前に答えない場合、Claude Code はコマンドを拒否し、Claude に代わりに何をするかを伝えるため、無人セッションは動作し続けます。
• プロンプトが開いている間に任意のキーを押すと、カウントダウンが停止し、プロンプトは答えを待ち続けます。
• セッション内でこれらのプロンプトが 3 回答えられずに終了した後、Claude Code はそれらの表示を停止し、重要なパスの削除をすぐに拒否します。新しいメッセージを送信するとカウントが再開されます。

時間制限は Claude Code v2.1.281 以降で適用されます。ターミナル外での auto モードの拒否も同様です。

ターミナル以外の場所では、このプロンプトは表示されません。

削除が拒否された場所ではどこでも、コマンド全体を読んでシェルで実行できます。

各モードでの動作を変更するには、CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT を 1 に設定します。

• bypassPermissions: ターミナルプロンプトに時間制限がなくなり、VS Code のチャットパネルでは承認を求めます
• auto: ターミナル、VS Code のチャットパネル、-p 実行、Agent SDK セッションで、分類器が判断します

この変数は、Claude Code の設定ファイルではなく、シェルや SDK の env オプションなど、Claude Code を起動する環境で設定します。チャットパネルの場合は、VS Code 自体のユーザー settings.json の claudeCode.environmentVariables に追加してから、新しい会話を開始します。

{
  "claudeCode.environmentVariables": [
    { "name": "CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT", "value": "1" }
  ]
}

bypassPermissions モードで重要なパスの削除のプロンプトをオフにする

bypassPermissions モードで、重要なパスをターゲットとする Bash の rm および rmdir コマンドをプロンプトなしで実行するには、環境に CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 を設定して Claude Code を起動します。これには Claude Code v2.1.311 以降が必要です。Claude Code はこの変数を起動環境からのみ読み取り、設定ファイルの env ブロック内では無視します。例えば、シェルで設定し、そこから claude を起動します。

macOS, Linux, WSL

export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

Windows PowerShell

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

Windows CMD

set CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

[!WARNING]

この変数を設定すると、破壊的な削除に対する安全のためのプロンプトが失われます。rm -rf ~ のようなコマンドが確認なしで実行される可能性があります。内容を失っても問題ない分離された環境でのみ設定してください。

削除がプロンプトなしで実行されるのは、plan モードではなく bypassPermissions モード自体の場合のみで、対象は Bash ツールと Monitor ツールで重要なパスのチェックが警告したものに限られます。これには Claude Code が完全に解析できないコマンドも含まれ、それらもプロンプトなしで実行されます。

重要なパスの削除のプロンプトに関する起動時の通知

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS が機能しているかどうかを確認するには、Claude Code が起動時に出力する行を読みます。-p 実行では、この行は stderr に出力されます。Agent SDK アプリでは、stderr オプションを渡して読み取ります。行には次のいずれかが表示されます。

• 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: 削除には通常のプロンプトまたは拒否が発生します。後でレジストリの読み取りに成功すれば、再起動なしで変数が有効になります。削除に対して引き続きプロンプトまたは拒否が発生する場合は、重要なパスの削除のプロンプトがオンのままになる理由を参照してください

行が表示されないからといって、プロンプトがオンになっているとは限りません。stderr オプションのない Agent SDK アプリでは行は表示されませんが、削除はプロンプトなしで実行される可能性があります。それ以外の場合は、起動環境で変数を設定したこと、セッションが bypassPermissions モードに入れること、claude が別のセッション内で実行されていないことを確認してください。一部のセッションは変数なしで起動します。

変数を設定していないのにこれらの行のいずれかが表示される場合は、シェルプロファイルなど、変数が設定されている場所を見つけて削除してください。

重要なパスの削除のプロンプトがオンのままになる理由

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS が効果を持たず、削除に通常のプロンプトまたは拒否が発生し続ける場合は、次のような原因を確認してください。

• 別の仕組みが権限プロンプトを処理している: --permission-prompts none なしの --permission-prompt-tool または Agent SDK の canUseTool コールバック、任意の matcher を持つ PermissionRequest フック、またはそのイベントを処理する mod。フック、mod、ツール、またはコールバックを削除して claude を再起動してください
• VS Code 拡張機能のチャットパネルまたはデスクトップアプリがセッションを実行している: 代わりに、IDE の統合ターミナルなどのターミナルで claude を起動してください
• ルールが Bash、Edit、または Read を対象としている: これらのツールのいずれかを対象とする拒否ルールまたは ask ルールが、起動時に存在するか、セッション中に Claude Code が読み取った場合です。後で削除しても該当します。ルールを削除して claude を再起動してください。ツールを除外するには、拒否ルールの代わりに --tools を使用してください
• permissions.blockReadsOutsideWorkingDirectories がオンになっている: この設定を true にしているすべての設定ファイルから設定を削除し、claude を再起動してください
• claude が別のセッション内で実行されている: セッションの Bash ツールまたはフックから起動された claude です。コマンドラインで変数を指定していても該当します。自分のシェルから claude を起動してください。このネストされたセッションの制限をセキュリティ境界として頼りにしないでください
• PreToolUse フックが削除に対して ask を返している: フックが返す内容を変更してください
• Claude Code がセッションを代わりに起動している: バックグラウンドセッション、分割ペインのエージェントチームのチームメイト、Remote Control サーバーが作成するセッションは、変数なしで起動します。自分のシェルから claude を起動してください
• 管理設定を読み取れない: Claude Code が管理設定のソースを正常に読み取れていません。サーバー管理設定の読み込みが失敗し続ける場合は、Remote managed settings failed to load を参照してください。レジストリのクエリ以外の失敗については、そのソースの管理者に修正を依頼してください
• Windows レジストリにクエリできない: Windows と WSL では、WSL が設定にレジストリを使用しない場合でも、この変数にはレジストリからの応答が必要です。英語以外の Windows、interop がオフの WSL、または WSL2 カーネル上のコンテナでは、クエリがセッション全体を通じて失敗する可能性があります。interop がオフの場合はオンにしてください。それ以外の場合は、それらの削除を自分で実行してください

PowerShell の Remove-Item

PowerShell ツールを有効にすると、Claude Code は Remove-Item と cmd ビルトイン rd、rmdir、del、erase に独自のチェックを与えます。これは rm 重要なパスリストとは別です。Remove-Item の場合、結果はターゲットに依存し、最初にマッチするケースが適用されます。

• システムパス。ファイルシステムルートとそのトップレベルディレクトリ、ドライブルートとそのトップレベルディレクトリ、およびホームディレクトリ。Claude Code はすべてのモードでコマンドを拒否し、承認を求めません。
• ワイルドカード。裸の *、または /* または \* で終わるターゲット（$dir/* のようなシェル変数の下のグロブを含む）。Claude Code は 分類器 がそれを見る前に、すべてのモードでコマンドを拒否し、承認を求めません。
• 作業ディレクトリまたはその親の 1 つ（-Recurse 付き）。Claude Code はコマンドを承認が必要な他のコマンドと同じように扱うため、承認を求めるモードでは承認を求め、auto モードでは分類器に送信し、dontAsk モードでは拒否します。bypassPermissions モードはこのチェックをスキップします。

システムパスのケースは、Claude が cmd /c rd /s /q C:\Users のように cmd を通じて実行する場合、rd、rmdir、del、erase にも適用されます。デフォルトでは、Claude Code はすべてのモードでそのようなコマンドを拒否し、承認を求めません。この cmd チェックには Claude Code v2.1.283 以降が必要です。

cmd ターゲットを判定する場合、Claude Code はリテラルテキストに続く PowerShell 変数を空として扱います。これにより cmd /c rd /s /q "C:\$name" は C:\ の削除となるため、これも拒否されます。末尾のワイルドカードはそれが空にするフォルダとしてカウントされるため、cmd /c del /q C:\* は拒否され、プロジェクト内の cmd /c del /q dist\* は拒否されません。

cmd チェックをオフにするには、Claude Code を起動する環境で CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY=1 を設定します。Claude Code はこの変数を設定ファイルの env ブロック内では無視します。システムパス上の Remove-Item はどちらの場合でも拒否されたままです。

関連項目

• Permissions：allow、ask、deny ルール。管理ポリシー
• Configure auto mode：分類器に組織が信頼するインフラストラクチャを伝える
• Hooks：PreToolUse および PermissionRequest フック経由のカスタム権限ロジック
• Security：セキュリティ保護とベストプラクティス
• Sandboxing：Bash コマンドのファイルシステムとネットワーク隔離
• Non-interactive mode：-p フラグで Claude Code を実行