権限モード

権限モード（permission mode）は、確認なしで Claude が実行してよい操作の範囲を決めます。Manual（設定値は default）ではファイル編集・シェルコマンド・ネットワークの多くで確認が入ります。auto モードでは、あなたの代わりに別のモデル（分類器、classifier）が操作を審査します。実行中のセッションでも、いつでもモードを変えられます。

• 6 つのモードは、便利さと監督のどこで折り合うかが違う
• CLI は Shift+Tab で切り替え、起動時は --permission-mode で指定する
• 既定で始まるモードは、バージョン・プラン・設定ファイルで決まる
• auto モードの分類器には、信頼するリポジトリやバケットを autoMode 設定で教えられる
• .git や .claude などの保護されたパスへの書き込みと、重要なパスの rm・rmdir は、モードによらず特別扱いされる

許可・拒否・確認のルールそのものは権限ルールにあります。このページは、その下敷きになるモードの話です。

モード一覧#

次の表は、各モードで確認なしに実行されるものです。Manual は設定値の default で載せています。

• 全操作を確認するモードの表示名は、CLI・claude --help・VS Code と JetBrains の拡張・デスクトップアプリで「Manual」。設定値は default（フックと SDK はこちらを使う）。CLI では値を入力する場所のどこでも別名の manual が使える（claude --permission-mode manual、"defaultMode": "manual"）。Manual の表示と manual の別名は v2.1.200 以降が必要
• 保護されたパスへの書き込みは、bypassPermissions と、bypass が使える対話端末のプランモード以外では自動承認されない
• ルールはモードの上に重ねる。拒否ルールはどのモードでも効き、bypassPermissions でも効く。許可ルールは bypassPermissions では意味を持たない
• 拒否・確認のルールは、Claude に呼べるツールがほかに 1 つ以上ある限り、EndConversation には適用されない

どのモードでも自動承認されないもの#

bypassPermissions を含め、次のものはどのモードでも自動承認されません。

• 明示的な ask ルールに一致したツール
• 組織が ask に設定したコネクタのツール（その設定が Claude Code に届くセッションで）
• ユーザーの操作が要るツール：組み込みの AskUserQuestion と、requiresUserInteraction が付いた MCP ツール
• 重要なパス（critical path）を対象にした rm と rmdir。許可ルールも PreToolUse フックの "allow" も承認できない
• セッション間メッセージの保護機能
• permissions.blockReadsOutsideWorkingDirectories がオンのときの、作業ディレクトリ外の読み取り。ファイルを読むと認識された Bash コマンドは auto と bypassPermissions でも確認が入り、承認が要るサンドボックス外での再実行も同じ（v2.1.257 以降）。シェルの構文解析で追えないコマンド（複数回の cd やサブシェル）は、外のパスを名指ししなくても同様に確認される。サンドボックス内で動き、サンドボックスがその制限を強制するときは対象外

目的別の組み合わせ#

• サンドボックスの auto-allow でも、拒否ルールは効き、Bash(git push *) のようにコマンドを名指しした ask ルールは確認が出る。設定ファイルからオンにするには sandbox.enabled を true にする
• auto モードは対応モデルが必要で、組織が無効にできる
• クラウドセッションは、設定ファイルの dontAsk と bypassPermissions を無視する
• -p で --dangerously-skip-permissions を使うと、それでも確認が出るはずの少数の呼び出しは拒否になる
• Bash サンドボックスと auto モードは独立していて併用できる。詳しくはサンドボックス

開始時のモードの決まり方#

端末で新しいセッションを始めるとき、次のうち最初に当てはまるものが使われます。

1. --permission-mode フラグ、または --dangerously-skip-permissions
2. 設定ファイルの permissions.defaultMode
3. 組み込みの既定

• .claude/settings.json か .claude/settings.local.json に "auto" を書いても効かず、~/.claude/settings.json の defaultMode ではなく組み込みの既定になる。同じ 2 ファイルの "bypassPermissions" も効かず、Manual で始まる。ほかの値はどの設定ファイルからでも効く
• 組み込みの auto 既定は、macOS・Linux・WSL で v2.1.228 以降、ネイティブ Windows で v2.1.233 以降が必要。それより前の既定は Manual
• 再開したセッションの開始モードはセッションの再開と管理を参照

組み込みの既定は、起動のしかたで決まります。上から順に、最初に当てはまる行が適用されます。

• インストールやアップグレード後の最初のセッションは、フィーチャーフラグが届く前に開始モードを選ぶことがあり、表と違うモードで始まることがある
• フラグ・設定・組み込みの既定が auto を選んでも、そのセッションで auto が使えなければ Manual で始まる。使えないのは、要件を満たさない（設定で無効・非対応モデル）か、Anthropic がサーバー側で一時的に止めているとき
• 組み込みの既定で auto で始まった最初のセッションでは、端末では先頭に 1 回、VS Code 拡張では閉じるまで残るカードで案内が出る
• ~/.claude/settings.json に auto 以外の defaultMode があり、ほかの設定ファイルに指定がなければ、そのモードで始まり続ける。Pro・Max・Team と、フィーチャーフラグを取得しないセッションでは、auto に変えるかを 1 回だけ聞かれ、断れば設定は変わらない

開始モードを変える#

複数の設定ファイルが指定したときの優先順位は設定ファイルの仕組みにあり、プロジェクトや管理設定の値が ~/.claude/settings.json に勝ちます。

{
  "permissions": {
    "defaultMode": "default"
  }
}

次のセッションからステータスバーに ⏸ manual mode on と出ます。

実行中にモードを切り替える#

CLI と JetBrains#

JetBrains のプラグインは IDE のターミナルで Claude Code を動かすので、CLI と同じ操作です。

• Shift+Tab でモードを巡回する。auto から押すとまず default になり、default → acceptEdits → plan と回る。任意のモードは plan の後ろに入る
• ステータスバーの表示は、default が灰色の ⏸ manual mode on、ほかは ⏵⏵ accept edits on・⏸ plan mode on・⏵⏵ auto mode on・⏵⏵ don't ask on・⏵⏵ bypass permissions on
• 起動時は claude --permission-mode plan のようにフラグで指定する。-p の非対話の実行にも同じフラグが使える

巡回に入るモードは次のとおりです。

• 任意のモードが複数あるときは bypassPermissions が先、auto が最後。両方あると、auto へ行く途中で bypassPermissions を通る
• Manual と acceptEdits で auto が使えるとき、Bash の確認に「Yes, and switch to auto mode」が加わる。承認と同時に auto へ切り替わる。PowerShell ツールの確認には出ない（v2.1.247 以降）。自分の ask ルールやフックが強制した確認には出ない（切り替えても確認は消えないため）

VS Code#

プロンプト欄の下のモード表示をクリックして選びます。

• VS Code のユーザー設定 claudeCode.initialPermissionMode に default・manual・acceptEdits・plan・bypassPermissions を書くと、会話の開始モードを固定できる。auto は書けない。Auto で始めたいときは、未設定のままモード表示から 1 回 Auto を選ぶ
• 新しい会話は、次の最初に当てはまるもので始まる：①claudeCode.initialPermissionMode、②モード表示で最後に選んだモード（Manual・Edit automatically・Auto のとき。Plan と Bypass permissions は、その会話だけ）、③管理設定か ~/.claude/settings.json の permissions.defaultMode、④プラン・プロバイダー・組織の設定による組み込みの既定
• プロジェクトの .claude/settings.json と .claude/settings.local.json は開始モードに使われない。claudeCode.claudeProcessWrapper を設定していると③④は使われず、①②がなければ Manual で始まる
• Bypass permissions は、拡張の設定の「Allow dangerously skip permissions」のオンが要る。オフだとモード表示に出ず、①③が bypassPermissions でも Manual で始まる。auto が使えないときの Auto も Manual で始まる
• ③は v2.1.283 より前は、フィーチャーフラグを取得するセッションの Pro・Max・Team プランだけに適用されていた
• 詳しくはVS Code と JetBrainsを参照

デスクトップアプリ#

Code タブの送信ボタンの隣のモードセレクターを使います。

• Auto は、auto モードが使えるときに出る
• Bypass permissions は、Pro・Max プランではデスクトップ設定の「Allow bypass permissions mode」のオンが要る。Team・Enterprise では組織のポリシーが決める
• Cowork タブはこれらのモードを使わない。独自のモードがあり、既定の外のモードを有効にするまでセレクター自体が出ない
• defaultMode を設定ファイルに書くと、デスクトップアプリが CLI と同じ設定ファイルを読み、新しいローカルセッションに適用する
• セレクターで選んだモードはフォルダごとに記憶され、そのフォルダでは defaultMode より優先される。Plan だけは現在のセッション限り
• 詳しくはデスクトップアプリを参照

Web とモバイル#

claude.ai/code かモバイルアプリで、プロンプト欄の隣のドロップダウンを使います。権限の確認は claude.ai に出て、そこで承認します。出るモードは、セッションが動く場所で決まります。

• Remote Control では、Bypass permissions 以外は、端末で設定したモードも含め、ドロップダウンにセッションの実際のモードが出る。アプリでも端末でも、変わるたびに更新される。デスクトップアプリや VS Code 拡張が動かすセッションも同様に変更を claude.ai へ報告する
• v2.1.202 より前は、/remote-control や claude --remote-control で接続したセッションがモードを報告せず、ラベルが実際と違うことがあった。ラベルだけの食い違いで、権限の確認は実際のモードで作られアプリにも出ていた
• Remote Control は、セッションを動かすローカルマシンが claude.ai アカウントでサインインしている必要があり、API キーは使えない。起動時に claude remote-control --permission-mode acceptEdits のようにモードを指定できる
• 詳しくはリモートコントロールとモバイルとクラウド（Web）で使うを参照

acceptEdits モード#

作業ディレクトリ内のファイルの作成と編集を、確認なしで許します。ステータスバーに ⏵⏵ accept edits on と出ます。

• ファイル編集に加えて、一般的なファイルシステムの Bash コマンド mkdir・touch・rm・rmdir・mv・cp・sed も自動承認される。LANG=C や NO_COLOR=1 のような安全な環境変数、timeout・nice・nohup のようなプロセスのラッパーが前に付いても同じ
• 自動承認は、作業ディレクトリか additionalDirectories の中のパスだけ。パスはシンボリックリンクの検査も通り、範囲の外に解決される書き込みは承認されない
• 範囲外のパス、保護されたパスへの書き込み、重要なパスを対象にした rm・rmdir、組み込みの読み取り専用セット以外のほかの Bash コマンドは、確認が出る
• PowerShell ツールが有効なら、範囲内のパスへの Set-Content・Add-Content・Clear-Content・Remove-Item（とその一般的な別名）も自動承認される。Remove-Item には別の検査がある（後述）。位置引数に引用符を含む Set-Content .\notes.txt "It's done" のような形は、静的に検証できないので確認が出る。-Value のような名前付きパラメータで渡すと出ない

plan モード#

Claude に、変更せずに調べて提案させるモードです。Claude はファイルを読み、調べるためのシェルコマンドを実行し、プランを書きますが、ソースは編集しません。bypass permissions が使える対話端末以外では、プランを承認するまで編集は止められます。

計画中のシェルコマンドの扱いは、最初に当てはまるものが適用されます。

1. bypass permissions が使える対話端末：分類器も確認も、計画中のコマンドには適用されない
2. auto モードが使えて useAutoModeDuringPlan がオン（既定でオン）：重要なパスの削除以外のシェルコマンドを、確認の代わりに分類器が審査する。承認されたものが実行され、却下されたものは止められる
3. auto モードが使えない、または useAutoModeDuringPlan がオフ：組み込みの読み取り専用セットの外のコマンドは確認が出る。サンドボックスの auto-allow が有効でも同じ

入り方は Shift+Tab、または 1 回のプロンプトの先頭に /plan を付けます。CLI からは claude --permission-mode plan。プランを承認せずに出るには、もう一度 Shift+Tab を押します。

プランをレビューして承認する#

プランができると、Claude が提示して次の選択肢を出します。

• 承認するとプランモードを出て、各選択肢が示すモードに切り替わり、Claude が編集を始める。もう一度計画するには Shift+Tab でプランモードへ戻るか、次のプロンプトに /plan を付ける
• Ctrl+G で、提示されたプランを既定のテキストエディタで開いて直接直せる。showClearContextOnPlanAccept が有効なら、プランを承認して計画のコンテキストを消す選択肢が先頭に加わる
• プランを承認すると、すでに名前を付けていなければ、プランから生成された題がセッションに付く（セッションの再開と管理）
• プロジェクトの端末セッションの既定にするには、.claude/settings.json の defaultMode を plan にする。VS Code 拡張は、ユーザー設定の claudeCode.initialPermissionMode を plan にする

auto モード#

分類器が、実行前に操作を審査します。依頼を超えてエスカレートするもの、見覚えのないインフラを対象にするもの、Claude が読んだ敵対的な内容に動かされているように見えるものは止めます。明示的な ask ルールは、引き続き確認を強制します。

• v2.1.283 以降は、端末と VS Code のセッションで、すべてのプランとプロバイダーの組み込みの開始モード。それより前は Pro・Max・Team だけ
• 分類器は、SendMessage で Claude が別のエージェントへ送る各メッセージ（プレーンテキストでもエージェントチームの構造化メッセージでも）も、配信前に auto モードと、分類器がコマンドを審査するプランモードで審査する。この送信の審査は v2.1.222 以降が必要
• 既定では、rm -rf / や rm -rf ~ のような重要なパスを対象にした rm・rmdir は審査しない（後述）
• auto モードは、確認の質問で止まらず作業を続けるよう Claude を促す。ただしプロンプトやスキルが明示的に質問に頼るときは聞く。確認が出るモードのままもっと自律的にしたいなら、Proactive の出力スタイルを使う

使える条件#

• auto が使えないと表示されたら、まず上の条件と、設定ファイルの disableAutoMode を確認する。Anthropic がサーバー側で止めているか、サーバーがそのアカウントの auto を拒否していることもある。どちらかの返事を受けたセッションは、終わるまで auto が使えないので、後で新しいセッションを始める
• モデル名を挙げて、auto モードが操作の安全性を「判断できない（cannot determine the safety）」と出るメッセージは、分類器へのリクエストが失敗したという意味。多くは一時的だが、Amazon Bedrock ではそのモデルを呼べるようになるまで繰り返すことがある。原因と対処はエラー一覧を参照
• defaultMode: "auto" を設定したのに、エラーなしで端末セッションが Manual で始まるなら、設定が .claude/settings.json か .claude/settings.local.json にある可能性が高い。~/.claude/settings.json へ移す。VS Code 拡張が始めた会話は、拡張自身の一覧を見る

Bedrock・Agent Platform・Foundry での auto モード#

これらのプロバイダーとサインイン済みの Claude apps gateway のセッションでは、auto は既定で使えます。ほかに何も指定がなければ、組み込みの開始モードでもあります。開発者に使わせないには、管理設定の disableAutoMode を "disable" にします。

• Shift+Tab の巡回から auto が消え、--permission-mode auto で始めたセッションは Manual で始まる
• すでに auto で動いているセッションは、管理者が配った設定がそのセッションに届くと auto を出て、auto mode disabled by settings と出る。v2.1.251 より前は、動いているセッションは終わるまで auto を保った
• v2.1.158〜v2.1.206 では、これらのプロバイダーで CLAUDE_CODE_ENABLE_AUTO_MODE=1 を設定するまで auto は無効で、変数がなければ defaultMode: "auto" も無視された。変数は互換のために受け付けられるが、v2.1.207 以降は効かない

サーバー側の分類器による審査#

auto モードでは、Claude Code が独自の分類器のリクエストを送る代わりに、審査が必要な操作の確認をセッションのモデルへのリクエストの一部として、サーバーに任せることがあります。次のセッションが該当します。

• Anthropic API への直接接続：対話端末のセッションと、-p・Agent SDK・VS Code 拡張・デスクトップアプリのセッションで、プランやアカウントの種類にかかわらず、Anthropic が展開を進めるにつれて有効になる。対話端末のセッションでは、Pro・Max・Team は v2.1.271 以降、Enterprise と Claude API アカウントは v2.1.278 以降が必要。-p・Agent SDK・VS Code 拡張・デスクトップアプリのセッションでは v2.1.281 以降が必要。v2.1.282 からは、フィーチャーフラグを取得しないセッション（テレメトリをオフにした場合など）は、どの種類のセッションでも既定でサーバーに任せる
• クラウドプロバイダー、または LLM ゲートウェイ・プロキシ：Claude Platform on AWS・Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry、ANTHROPIC_BASE_URL を LLM ゲートウェイやプロキシに向けたときはプランによらず。既定でサーバーに任せるには v2.1.278 以降が必要
• サインイン済みの Claude apps gateway のセッション：v2.1.280 以降が必要

サーバーが審査する場合は、その判定で決まります。ほかに 2 つの結果があります。

• サーバーがセッションを審査しない（結果なしで応答が完了する、またはサーバーが審査しないと答える）：Claude Code は自前の分類器のリクエストに戻る。原因で多いのは、審査の依頼や結果を落とす LLM ゲートウェイ・プロキシ、サーバー側の検査がまだないプラットフォーム・リージョン・認証情報。残りのセッション中その戻しが続くと、分類器リクエストが課金されるアカウントでは、その料金の通知が出る
• サーバーが操作に判定を返さない：Claude Code は審査なしで実行せず、操作を拒否する。応答が審査結果の到着前に終わる、結果が読めない形で届く場合で、応答を途中で切る・結果を書き換える LLM ゲートウェイやプロキシが原因になりうる。Anthropic API への直接接続では、サーバーの検査がタイムアウトなどで失敗したときも起きる。拒否のメッセージ・拒否が繰り返されたときの動き・対処はエラー一覧を参照

サーバーに任せず、いつも Claude Code 自身の分類器リクエストを使うには CLAUDE_CODE_AUTO_MODE_SERVER=0 を設定します。Anthropic API への直接接続では v2.1.281 以降が必要です。1 にすると、まだ審査がないセッションでサーバー審査がオンになります。ただし CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 も設定していると効きません。CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 を設定し CLAUDE_CODE_AUTO_MODE_SERVER を未設定にしても、Claude Code はサーバーに任せなくなります（例外は ゲートウェイのプロトコルの文書にある）。

分類器が既定でブロックするもの#

分類器が信頼するのは、作業ディレクトリと、セッション開始時にそのディレクトリに設定されていたリモートだけです。セッション中に git remote add や git remote set-url で追加・向け直したリモートは信頼されません（v2.1.200 より前は、途中で追加したリモートも信頼された）。それ以外は、autoMode で信頼するインフラを設定するまで外部として扱われます。

既定でブロックされるもの：

• 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 や bot の /deploy・/merge のような、自動化へのコマンドそのものになるコメントの投稿

• 本番のフィーチャーフラグの切り替え・展開・削除

• 保護された IaC の範囲へのインフラ変更の適用、クラスターのノードの排出と削除

• 名指ししたリソースを超えて届く共有計算クラスターへの書き込み（ラベルセレクターや、他のユーザーのジョブを巻き込む --all など）

• 全ノードで動く、またはクラスターの通信を横取りする Kubernetes リソース（DaemonSet・admission webhook）の作成

• 機微なリモート対象への対話シェルやポートフォワード

• ローカルのサービスを公開インターネットから届くようにするトンネルやリバースシェル

• 生の認証情報やトークンを、記録やファイルに出力すること

• 環境で機微なデータの場所に挙げた場所へのアクセス、そこからのデータの持ち出し、その場所のデータを項目が除外した宛先へ送ること

• 内部のパッケージレジストリを迂回して公開レジストリからインストールすること。環境に内部レジストリやミラーを挙げているときも、会話で Claude にあると伝えたときも対象

• --insecure のような、安全装置を外すフラグ付きのコマンド

• 人の承認もサンドボックスもなしで動く自律エージェントのループの起動（--dangerously-skip-permissions や --no-sandbox で始めたものなど）。隔離と操作ごとの承認を切ったサードパーティのエージェントや評価ハーネス（--yes-always で始めたランナーなど）の実行も含む

• ページの内容・cookie・認証情報をオリジンの外へ送りうる Claude in Chrome のブラウザ操作

• /tmp・$TMPDIR・共有のスクラッチやキャッシュのディレクトリのファイルを、名指しのパスではなくワイルドカード・グロブ・経過時間で削除すること

• 他の人や共有システムへ送る・アップロード・公開・書き込みする内容に、その宛先向けに自分のメッセージが認めていない機微な詳細を含めること。リポジトリが信頼の境界の外か公開（組織自身の公開リポジトリも含む）なら、PR・Issue の本文・コミットメッセージ・コメントも対象で、内部のファイルパス・コードネーム・メールやアカウント識別子のような API の実データ・インフラの識別子が機微な詳細にあたる。PR・Issue・コミットメッセージへの絞り込みは v2.1.200 以降が必要

• Claude Code 自身の tmux ペインへキー入力を送って自分の画面を操作すること（Claude が自分の権限や監督を変えるものとして扱われる）

これらの一部は、機微なリモート対象や保護された IaC の範囲のように、環境の項目で具体的な名前に絞れます。

v2.1.200 以降で、さらに次もブロックされます。

• セキュリティの挙動（認証・アクセス制御・入力検証・サンドボックス）を守るテストやアサーションのコメントアウト・削除・強制パス
• セッション中に Claude が作っていない、状態を持つリソースの削除や解体（より具体的な削除ルールがなく、あなたが名指ししていないとき）
• API のベース URL・プロキシのエンドポイント・webhook の受け口・レジストリのミラーを、作業に合わないサードパーティのホストへ向け直すこと（.env.example のような例のファイルも含む）
• git remote set-url や git remote add でプッシュ先を変えること（新しいリモートを名指ししたときを除く）
• シークレットや個人・預かりのデータを、公開と分かっているリポジトリへプッシュすること、そのリポジトリ自身の作業ではない機密を公開リポジトリへプッシュすること。dotfiles のリポジトリでは、その内容自体にあたる個人・預かりのデータは例外で、非公開リポジトリの内容が公開の場に届くのも同様にブロックされる（この 2 点の細分化は v2.1.203 以降）。リポジトリの公開・非公開が分からないときは、それだけではブロックせず、内容をほかのルールで判断する
• 別のリポジトリや組織へのプルリクエスト、gh repo fork でのフォーク、サードパーティのリポジトリへのプッシュ（その外部の対象を名指ししたときを除く）

v2.1.203 以降で、さらに次もブロックされます。

• 機微なローカルの保管場所の内容、または名前・パス・種類で機微と分かるファイルの内容を、コミット・プッシュ・PR や Issue の文面・gist やペースト・パッケージの公開に入れること（取得元と宛先の両方を名指ししたときを除く）。セッションの記録や会話ログ、SSH 鍵・クラウドの認証情報・ブラウザのプロファイル・シェル履歴のような認証情報や設定のドットフォルダ、ユーザーデータのエクスポートがすべて対象で、リポジトリが非公開でも解除されない

v2.1.205 以降で、さらに次もブロックされます。

• ~/.claude/projects/ か設定した設定ディレクトリの下の Claude Code のセッション記録（.jsonl）への書き込み。直接でもシェルコマンド経由でも、各エントリに足すメタデータ行も含む。読み取りは止めない
• 対象が、会話の中で割り当てられていないシェル変数（またはそれを根にしたグロブ）である再帰的な強制削除（rm -rf "$VAR" や Remove-Item -Recurse -Force $dir）。値が以前のコマンド出力にしかなく、分類器はそれを受け取らないので、削除の対象を確かめられない。ブロックは、削除するパスを名指ししたとき、または Claude が解決済みの実パスをコマンドに書いてやり直したときに解ける。分類器が対象を解決できる削除には影響しない。rm -rf "$VAR"/* のように変数の直下のグロブは重要なパスとして扱われ、Remove-Item で対象が単独の * か /*・\* で終わるものは分類器に届かず拒否される

v2.1.257 以降で、さらに次もブロックされます。

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

これらのどれかを許すはずの環境で動かしているなら、autoMode.environment の「Host containment」の項目にその構成を書きます。

v2.1.261 以降で、さらに次もブロックされます。

• URL 自体が共有する内容を運んでいる、公開のペースト・図・データ共有サービスへのリンクを、メッセージ・PR や Issue の文面・文書など、開かれたり取得されたりする場所に書くこと（そのサービスを名指ししたときを除く）

既定で許可されるもの：

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

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

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

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

• 作業中のリポジトリのどのブランチ（既定ブランチを含む）へのプッシュ。production や gh-pages のように、デプロイや公開の対象と分かる名前の既定以外のブランチは除き、分類器がそのプッシュを個別に判断する。内容はほかのルールで検査され、permissions.deny ルールは書かれたとおりのプッシュのコマンドを全モードで止められ、リモートのブランチ保護も効く。v2.1.211 より前は、開始時のブランチ・Claude が作ったブランチ・既定ブランチへの通常のプッシュだけが既定で許可されていた

• 同じセッションで Claude が以前に作ったジョブの削除

• 依頼の一部としてのセキュリティ関連のコード・設定・脅威モデルの読み取り・レビュー・作成

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

• environment に挙げた信頼するドメイン・バケット・サービスへのデータ送信（データの流れだけで、同じインフラへの破壊的な操作や認証情報の操作は含まない）

• 信頼する内部ドメイン・localhost・名指ししたURLへの Claude in Chrome のナビゲーション

• サンドボックス内のコマンドは、既定ではネットワークに出られない。Claude がコマンドに必要なホストを名指しし、分類器がそれをコマンドと一緒に審査し、承認された一覧がそのコマンドだけのためにホストを開く。詳しくはサンドボックス

• 全ルールの一覧を JSON で見るには claude auto-mode defaults。日常の操作がブロックされるなら、管理者が autoMode.environment に信頼するリポジトリ・バケット・サービスを足せる

• 作業中のリポジトリへのプッシュと、依頼に沿ったプルリクエストの作成は確認なしで動く。ただし、シークレットの流出や別のリポジトリ・組織へのプルリクエストなど、ブロックの一覧に当たるものは別。この 2 つの前に人の確認を挟みたいなら、書かれたとおりのコマンドに一致する permissions.ask ルールを足す

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

permissions.blockReadsOutsideWorkingDirectories がオフの間、auto モードのファイル読み取りは、作業ディレクトリの外でも確認なしで動きます。ただし、Read・Grep・Glob ツールが外のパスを初めて使うときは、その読み取りを許すかを聞かれます。-p の非対話の実行とバックグラウンドのセッションには出ず、そこでの読み取りは今までどおり動きます。どう答えても Claude は作業を続けます。

会話で伝える境界と承認#

• 境界：「push しないで」「レビューするまでデプロイを待って」のように会話で伝えた境界は、分類器がブロックの合図として扱う。既定のルールが許す操作でも、一致するものは止められ、後のメッセージで解くまで続く。Claude 自身が条件が満たされたと判断しても解けない。境界はルールとして保存されず、分類器が毎回記録から読み直すので、圧縮でそのメッセージが消えると失われうる。確実に守るなら拒否ルールを使う
• 承認：ブロックされた操作を許すと Claude に伝えると、分類器がそれを承認として読み、ブロックを解けることがある。操作と、それを危険にしている具体的な点（force push なら対象のブランチなど）の両方を名指しする必要がある（動詞だけの「force-push していい」では解けない）。承認は、名指しした破壊的な操作 1 回分にしか及ばず、継続的な承認として与えない限り、次の操作はまたブロックされる。日常のパターンを 1 つずつ承認しなくて済むように、autoMode.allow に足す。承認が届かないブロックもあるので、その手順を動かすには auto モードを出て、権限の確認に答える

auto モードが後退するとき#

• ブロックされた操作：通知が出て、/permissions の「Recently denied」タブに載る。r で、手動承認つきの再試行ができる
• 繰り返しのブロック：分類器が同じ操作を連続 3 回、または合計 20 回ブロックすると、auto モードは止まって確認が戻る。確認された操作を承認すると auto モードに戻る。数え方は次のとおり
• 分類器の判定なし：auto モードとは別の安全検査が分類器自身のリクエストを拒む、または分類器の応答が解釈できないときは、通知も「Recently denied」の記録もなしで操作を拒否する。メッセージと対処はエラー一覧を参照
• サーバーの判定なし：サーバー側の審査では、判定がない操作は拒否され、判定なしの応答が 10 回続くとターンが止まる
• 確認中のモード切り替え：分類器の確認の最中にモードを切り替えると、新しいモードが求めない判定は捨てられる。確認が出る、dontAsk なら自動で拒否される

3 回連続・合計 20 回のしきい値は変えられません。合計の回数はセッションを通じて残り、その上限が後退を起こしたときだけ戻ります。auto モードとは別の安全検査が分類器自身のリクエストを拒んだ場合の拒否は、どちらにも数えません。--permission-prompt-tool のない非対話の -p の実行には、戻れる確認がないので、しきい値に達すると操作は実行されず、Claude は作業を続けます（実行は止まりません）。

判定の順序とサブエージェント、コスト#

各操作は決まった順序で判定され、最初に一致した段階が勝ちます。

1. 許可・確認・拒否のルールに一致した操作は、その場で決まる。例外：

   • 保護されたパスへの書き込みは、許可ルールに一致しても分類器へ回る
   • 重要なパスの rm・rmdir は、どの許可ルールも承認しない
   • requiresUserInteraction の MCP ツールと、組織が ask にしたコネクタのツールは、許可ルールに一致してもあなたに直接確認する
   • コマンドごとの許可ドメインを持つシェルコマンドも、許可ルールに一致しても分類器へ回る（ルールが承認するのはコマンドで、そのホストではないため）
   • コマンドの内容に一致する ask ルール（Bash(git push *) など）は、権限の確認に戻る
   • シンボリックリンクの検査で保護されたパスに解決される書き込みは、要求されたパス自体が保護されていないとき、確認が出る

2. 読み取り専用の操作と、作業ディレクトリ内のファイル編集は自動承認される。ただし保護されたパスへの書き込みと、作業ディレクトリの外での最初の読み取り（確認が出る）は除く

   • サーバー側の審査があるセッションでは、読み取り専用とサンドボックス内のシェルコマンドは、その審査を待ち、フラグが立てば止められる
   • 作業ディレクトリ内の書き込みがシンボリックリンクの検査で外に解決されると、確認が出る
   • Claude が他の人が作ったアーティファクトを読むときは、そのページに挙げた承認の場合が当てはまる

3. それ以外はすべて分類器へ。既定の扱いの重要なパスの削除は除く。ステップ 1 で直接確認が出たコネクタのツールと requiresUserInteraction の MCP ツールも分類器には届かない

4. 分類器がブロックしたら、Claude に理由が渡る。多くのセッションで、理由は文章による説明ではなく、一致したルール名（[Data Exfiltration] など）

   インストールした Mod（モッド） が tool.check を扱うと、ステップ 3 の前に操作を承認でき、Mod が承認した操作を分類器は確認しない。フックで権限を拡張するを参照

   VS Code 拡張では、Claude in Chrome のブラウザ操作がどう承認されるかは、セッションがブラウザにどう接続したかで決まる。Chrome とコンピュータ操作を参照

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

• 単独の Bash(*) と PowerShell(*)
• Bash(python*) のようなインタープリターのワイルドカード
• パッケージマネージャーの run コマンド
• Agent の許可ルール
• Monitor の許可ルール（Claude Code が Monitor のコマンドをシェル経由で実行するため）

Bash(npm test) のような絞ったルールは有効なままで、auto モードを出ると外したルールが戻ります。v2.1.236 より前は Monitor の許可ルールが auto モードで有効なままで、ツール全体に一致するルールが分類器の審査なしに Monitor のコマンドを承認していました。

• Claude Code は、git reset --hard や rm -rf のように未コミットの作業を捨てうるコマンドの前に自分で git status を実行し、ステージ済み・変更済み・未追跡の作業があるかを分類器に見せる。リポジトリの git 設定が status.showUntrackedFiles=no でも、この検査では未追跡ファイルを報告する
• Claude Code 自身が送る分類器のリクエストでは、分類器が見るのはユーザーのメッセージ、ファイル読み取りや検索のような読み取り専用の参照以外のツール呼び出し、CLAUDE.md の内容。ツールの結果は取り除かれるので、ファイルや Web ページの敵対的な内容は分類器を直接操作できない
• PostToolUse フックの classifierContext フィールドで、呼び出しの結果に注釈を付けられる。分類器はアプリが与えた文脈として読む（v2.1.236 以降）。詳しくはフックのリファレンス
• 別のサーバー側のプローブが、届くツールの結果を走査し、Claude が読む前に怪しい内容へ印を付ける

サブエージェントの作業は 3 か所で審査されます。

1. 起動前：委任するタスクの説明が評価され、危険そうなタスクは生成の時点でブロックされる
2. 実行中：各操作が親と同じ判定の順序とブロック・許可のルールを通る。サブエージェントの frontmatter の permissionMode は無視される
3. 終了時：親が報告を読む前に、分類器がその作業と最終報告を審査する。分類器が作業や報告にフラグを立てるか、別の API 安全検査が審査を拒むと、報告は先頭にセキュリティ警告を付けて渡される。審査に分類器が使えないときは、行動する前にサブエージェントの作業を確かめるよう添えて渡される

コストと遅延：

• 分類器は既定で、/model の選択ではなく Claude Sonnet 5 で動く。Anthropic がサーバー側で設定した分類器のモデルがあれば、既定より優先される。セッションのモデルが Claude Sonnet 4.6 のとき、または availableModels が Sonnet 5 を除いているときは、セッションのモデルで動く。セッションが Fable 系のモデルなら Opus。Anthropic API 以外のプロバイダーでは、その Opus は ANTHROPIC_DEFAULT_OPUS_MODEL に設定したモデルで、設定していなければ Opus 5
• セッション最初の auto モードのリクエストが Sonnet 5 の既定を確かめる。成功すれば Sonnet 5 が分類器のモデルのままで、モデルが使えず失敗したらフォールバックを使う
• Enterprise プランと、Claude API・Claude Platform on AWS・Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry を使うアカウントでは、分類器の呼び出しがトークン使用量に数えられる。各検査は記録の一部と保留中の操作を送るので、実行前に往復が 1 回増える。読み取りと、保護されたパス以外の作業ディレクトリ内の編集は分類器を通らないので、オーバーヘッドの大半はシェルコマンドとネットワーク操作から来る。サーバーがセッションのモデルへのリクエストの一部として審査する場合は、数えるべき別の分類器の呼び出しはない
• サンドボックスのネットワークアクセスは、接続ごとの分類器リクエストを増やさない。分類器はコマンドが名指しするホストをコマンドと合わせて 1 回で審査し、Claude Code は各接続を承認済みの一覧と照らすだけ

auto モードを設定する（autoMode）#

分類器は既定で、作業ディレクトリと現在のリポジトリのリモートだけを信頼します。自社のソース管理の組織や、チームのクラウドバケットへの書き込みは、autoMode.environment に足すまでブロックされます。auto モードのオン・オフの操作は、上の各節にあります。

人の確認を足す#

最も直接的なのは permissions.ask です。コマンドの内容を絞った ask ルールは、分類器より先に評価され、auto モードでも必ず確認を出します。

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

• 一致するのは git push か gh pr create で始まるコマンド。git -C <dir> push や git -c <key>=<value> push のような書き方は一致しないので、確認の対象にならない。コマンド全文を検査する確認が要るなら PreToolUse フックを足す（フックのリファレンス）
• 既定では、auto モードは作業中のリポジトリのどのブランチ（既定ブランチを含む）へのプッシュと、プルリクエストの作成を許す。production・release・gh-pages のように、デプロイや公開の対象と分かる名前の既定以外のブランチは、その既定の対象外で、分類器が本番デプロイを含めて個別に判断する。内容も検査されるので、force push、コミットに入るシークレット、CI やデプロイのパイプラインが動いたときにリポジトリの外へシークレットを送る変更は、引き続きブロックされる

境界の強さに合わせて仕組みを選びます。

分類器が設定を読む場所#

分類器は、Claude 自身が読み込むのと同じ CLAUDE.md の内容を読みます。「force push しない」のような指示は、Claude と分類器の両方を同時に導きます。プロジェクトの慣習と振る舞いのルールは、まずここに書きます。プロジェクトをまたぐルール（信頼するインフラ、組織全体の拒否ルールなど）は autoMode 設定のブロックを使います。分類器が autoMode を読む範囲は次のとおりです。

• プロジェクトの .claude/settings.json と .claude/settings.local.json の autoMode は読まれない（どちらもリポジトリの中にあり、チェックインされたリポジトリやビルド手順が自前の許可ルールを差し込めてしまうため）。.claude/settings.local.json にある autoMode は ~/.claude/settings.json へ移す
• 各範囲の項目は合算される。開発者は environment・allow・soft_deny・hard_deny に個人の項目を足せるが、管理設定が与える項目は消せない。分類器の中では許可ルールがソフトなブロックの例外として働くので、開発者が足した allow 項目が組織の soft_deny 項目を上書きしうる。合算は足し算で、厳密な方針の境界ではない
• 何があってもユーザーの意図や分類器の設定にかかわらず動かしてはならない操作には、管理設定の permissions.deny を使う。分類器より前にブロックし、上書きできない

信頼するインフラを定義する（autoMode.environment）#

多くの組織で設定が要るのは autoMode.environment だけです。分類器に、信頼するリポジトリ・バケット・ドメインを教えます。分類器は「外部」の意味をこれで決めるので、挙げていない宛先は持ち出し先になりうるものとして扱われます。claude auto-mode defaults は、3 種類の環境項目を出します。

文脈のスロットは次のとおりです。

• 非公開リポジトリは機密の宛先として許容されるが、リポジトリを非公開にしても、シークレットや個人・預かりのデータがそこへ許されるようにはならない（リポジトリの公開範囲が絞るのは機密だけ）
• 既定の項目に自分のものを足すには、配列に文字列 "$defaults" を入れる。既定の項目がその位置に差し込まれ、自分の項目は前にも後にも置ける

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}

• 保存したら claude auto-mode config で、有効なルールに自分の項目が入っているかを確かめる
• 項目は正規表現でもツールのパターンでもなく、自然言語のルール。新しいエンジニアにインフラを説明するように書く
• 書くとよいこと：組織と主な用途（ソフトウェア開発・インフラの自動化・データエンジニアリング）、開発者がプッシュする GitHub・GitLab・Bitbucket の組織すべて、読み書きさせたいバケットの名前や接頭辞、*.internal.example.com のような内部ドメイン、CI・成果物のレジストリ・内部のパッケージインデックス・インシデント用のツール、インストールを通すべきプライベートの npm・PyPI などのレジストリ（迂回して公開レジストリへ行くインストールをブロックするため）、個人データ・機密のビジネスデータ・認証情報・規制対象のデータなどを持つバケット・データベース・パスと、そのデータを共有してよい相手、本番として扱う名前空間・ホスト・コンテナ（そこへのリモートシェルやポートフォワードに明示の承認を要する）、apply や destroy のたびに変更を名指しさせたいインフラのリソース、規制のある業界・マルチテナントのインフラ・コンプライアンスなど分類器の判断に効く追加の文脈
• 一度に全部を埋める必要はない。まず既定のままで、ソース管理の組織と主要な内部サービスを足すと、自社リポジトリへのプッシュのような、最も多い誤検知が解ける。次に信頼するドメインとクラウドバケット、残りはブロックが出たときに足す

雛形：

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}

/auto-mode-setup で項目を作る#

/auto-mode-setup は、プロジェクトとそこでの最近のセッションから、autoMode.environment の項目（場合によっては後述のルール項目も）の下書きを Claude Code に作らせます。下書きを受け入れると ~/.claude/settings.json へ書かれます。

• Pro・Max・Team プランと v2.1.228 以降が必要。ネイティブ Windows は v2.1.233 以降。クラウドセッションでは実行できない。フィーチャーフラグの取得が要るので、取得を切ったセッションでは実行できない
• ~/.claude/settings.json にすでに autoMode の項目があると、まず環境の一覧に足すか置き換えるかを聞かれ、どちらでも自分で書いたルールは残る。続けてこのプロジェクトの使い方を聞かれ、走査の前に 2 つの任意の走査が提案される
• 走査で必ず読むもの：このプロジェクトの CLAUDE.md・README.md・設定ファイル・git のリモート、autoMode と permissions.allow の設定、最近のセッションで Claude が実行したコマンドのホスト・バケット・コマンド名（あなたのメッセージは読まない）
• 任意の走査が足す読み取り：シェル履歴の各コマンドの最初の単語、ホームディレクトリ以下のリポジトリのリモートのホストと名前
• 下書きは全体を受け入れるか捨てるかで、1 項目ごとの調整は後で ~/.claude/settings.json を直す。受け入れると、既存の設定と突き合わせて書かれる：environment の一覧は "$defaults" なしで書かれる（下書きが変えなかった組み込みの項目を明記するため）。下書きが項目を足した allow・soft_deny・hard_deny の一覧には、すでに "$defaults" なしの allow を書いていない限り "$defaults" が入る。保存後、~/.claude/settings.json の permissions.allow ルールのうち、auto モードが無視するもの（Bash(*) など）や破壊的なコマンドを自動承認するものを消すか聞かれる
• 結果は claude auto-mode config で確かめる

auto モードが数回ブロックしたのに autoMode.environment の項目がまだないと、ターンの終わりに「Teach auto mode about your environment?」というダイアログが出て、/auto-mode-setup を実行するかを聞かれます。案内だけを止めてコマンドは残すには、そのダイアログで「Don't show again」を選びます。コマンドも案内も両方止めるには、~/.claude/settings.json に次を足します。

{
  "skillOverrides": {
    "auto-mode-setup": "off"
  }
}

/auto-mode-setup は同梱のスキルではなく組み込みのコマンドですが、この skillOverrides は効きます。ただし disableBundledSkills ではオフにできません。

ブロックと許可のルールを上書きする#

分類器の組み込みのルールの一覧を置き換える 3 つのフィールドがあります。それぞれ自然言語のルールの配列です。分類器より前に動くツールのパターンによるハードなブロックは permissions.deny を使います。

分類器の中の優先順位は 4 段階です。

1. hard_deny：無条件にブロックする。ユーザーの意図も allow の例外も適用されない
2. soft_deny：次にブロックする。ユーザーの意図と allow の例外が上書きできる
3. allow：一致する soft_deny を例外として上書きする
4. 明示的なユーザーの意図：残るソフトなブロックを上書きする。ユーザーのメッセージが、Claude がしようとしているまさにその操作を直接かつ具体的に書いていれば、soft_deny に一致しても許される

一般的な依頼は明示的な意図に当たりません（「リポジトリを片づけて」は force push を認めないが、「このブランチを force-push して」は認める）。緩めるには、既定の例外が覆わない日常のパターンを分類器が繰り返し止めるとき allow に足します。締めるには、既定が見逃す環境固有の破壊リスクを soft_deny に、決して越えてはならないセキュリティ境界を hard_deny に足します。組み込みのルールを残して自分のを足すには "$defaults" を入れます。リリースで組み込みの一覧が変わっても、その更新を引き継げます。

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "$defaults",
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

• 各節は独立して評価される。environment だけを設定しても、既定の allow・soft_deny・hard_deny はそのまま
• 一覧を完全に自分のものにするときだけ "$defaults" を省く。安全にやるには、claude auto-mode defaults で組み込みのルールを出し、設定ファイルに写し、自分のパイプラインとリスクの許容度に照らして 1 つずつ見直す

/permissions から編集する#

設定ファイルを開かずに分類器のルールと environment の項目を見て直すには、/permissions を開いて「Auto mode」タブを選びます。タブは v2.1.246 以降が必要で、auto モードがそのセッションで使えるときだけ出ます。管理設定か --settings フラグの項目は読み取り専用で出て、タブでの変更はすべて ~/.claude/settings.json に保存されます。

すべてのシェルコマンドを分類器に通す#

既定では、Bash(npm test) のような絞った Bash・PowerShell の許可ルールは auto モードでも有効で、分類器の前に解決されます（コマンドごとの許可ドメインを持つコマンドを除く）。外されるのは、Bash(*) やワイルドカードのインタープリターのような任意のコード実行を許す広いルールと、Monitor を名指しするすべてのルールだけです。そのため、絞ったルールでも、分類器が見ない破壊的な引数を通しうることがあります。autoMode.classifyAllShell を true にすると、auto モードの間、Bash と PowerShell の許可ルールをすべて停止し、許可リストにかかわらず、重要なパスの削除以外のすべてのシェルコマンドを分類器が評価します。

{
  "autoMode": {
    "classifyAllShell": true
  }
}

• 遅延と引き換えに網羅性を得る設定。許可ルールが即座に承認したはずのコマンドが分類器の判定を待ち、シェルコマンドごとに分類器の呼び出しが 1 回数えられる
• 効くのは auto モードが有効な間だけで、ほかのモードでは許可ルールは普通に働く

auto-mode サブコマンド#

defaults と config は、4 つのルールの一覧を、各ルールを自然言語の文字列とした 1 つの JSON オブジェクトで出します。

ブロックを確かめて直す#

「Recently denied」タブ（/permissions）には、分類器が拒否した操作が記録されます。r を押すと再試行の印が付き、ダイアログを出るとき、モデルにその呼び出しを再試行してよいと伝えるメッセージが送られて会話が再開します。分類器が判定を出さなかった場合（auto モードとは別の安全検査が分類器自身のリクエストを拒んだ、または応答が解釈できなかった）は、この記録には載らず拒否されます（エラー一覧）。

• ブロックされた呼び出しは会話の中で探す。「Ran 3 shell commands」のように畳まれているときは Ctrl+O でトランスクリプトビューアーを開くと展開される
• 入力欄の近くの bash denied by auto mode · [Data Exfiltration] · /permissions のような通知はツールと理由だけを出し、「Recently denied」のタブはシェルコマンドを Claude が書いた説明で出す。どちらもコマンドや URL は出さない。正確な入力を機械的に得るには、tool_input として受け取る PermissionDenied フックを足す
• 呼び出しの下の文で、直すことがあるかが分かる。モデルが is temporarily unavailable のような分類器自体の問題を示すなら、最終判定なしにブロックされたということで、対処はエラー一覧にある。そうでなく Denied by auto mode classifier に [Production Deploy] のような理由が付く、または Blocked by classifier なら、分類器が危険と判断した。呼び出しが届こうとしたものや、しようとしたことから直し方を選ぶ

• 環境の項目や allow ルールは、/permissions ダイアログの「Auto mode」タブから足せる
• [Data Exfiltration] のように角括弧で囲まれた語は、一致したルールの名前。ルールの全文は claude auto-mode defaults で読める
• 同じ宛先でのブロックが繰り返されるなら、分類器が文脈を欠いている。その宛先を autoMode.environment に足すか、/auto-mode-setup で下書きを作らせ、claude auto-mode config で反映を確かめる

dontAsk モード#

確認になるはずのツール呼び出しをすべて自動で拒否するモードです。Manual で確認が要らない操作（作業ディレクトリ内のファイルの読み取り、読み取り専用の Bash コマンド）、permissions.allow に一致する操作、PreToolUse フックが承認した呼び出しは動きます。CI のパイプラインや、許すことを事前に決めた制限のある環境に使います。セッションは入力を待ちません。ステータスバーには ⏵⏵ don't ask on と出ます。

• 明示的な ask ルールに一致する呼び出しは、確認ではなく拒否される
• 組み込みの AskUserQuestion ツールは、許可ルールに一致しても拒否される。組織が ask にしたコネクタのツール（その設定が Claude Code に届くセッション）も拒否される
• _meta["anthropic/requiresUserInteraction"] が付いた MCP ツールも拒否される（承認カードがこのモードの集めない答えを要るため）
• rm -rf / や rm -rf ~ のような重要なパスの rm・rmdir は、許可ルールに一致しても PreToolUse フックが承認しても拒否される
• クラウドセッションは defaultMode: "dontAsk" を無視する
• 起動時は claude --permission-mode dontAsk で指定する

bypassPermissions モード#

権限の確認と安全検査を無効にし、ツール呼び出しをすぐ実行します。保護されたパスへの書き込みも含みます。

• 上の「どのモードでも自動承認されないもの」は、このモードでも確認が出る。他の組織の公開アーティファクトの読み取りには承認が要り、このモードはそれを求めないので、Claude はそれを読めない。PowerShell の Remove-Item の拒否も、このモードで適用される
• セッション間メッセージ（セッション間のメッセージ）の 2 つの保護は、このモードと、bypass が使える対話端末のプランモードセッションでも残る。1 つは、このマシンの外にある自分のセッションへのメッセージの isolatePeerMachines の承認確認。もう 1 つは、crossSessionInbound の値が適用されないとき、自分の別のセッションからの受信メッセージを承認のために保留し、送り主のセッションが自分も権限の確認を飛ばしていると名乗るときだけ、確認なしで届ける。メッセージを保留している間にモードを出ると、Claude Code が受信のルールを適用し直し、いま受け入れられる保留中のメッセージを届ける
• bypass が使える対話端末では、Claude Code はプランモードのブロックも強制しない。Claude は編集せずに計画するよう指示されたままだが、計画中に試みたファイル編集やシェルコマンドは確認なしで動く。明示的な ask ルールと、重要なパスの rm・rmdir は確認が出る
• 対話端末のないところ（-p の非対話の実行・Agent SDK のセッション・VS Code 拡張のチャットパネルの会話）では、プランモードのブロックが保たれる。そこでは --allow-dangerously-skip-permissions で、後から bypassPermissions を選べるようにする
• 有効にせずに始めたセッションからは入れない。起動時に permissions.defaultMode: "bypassPermissions" か、有効にするフラグで指定する
• --dangerously-skip-permissions は claude --permission-mode bypassPermissions と同等。--restricted で始めたセッションでは bypassPermissions を拒否する（--restricted は v2.1.248 以降が必要）
• このモードを有効にして対話セッションを初めて始めると、確認なしの操作の責任を引き受けるかを聞く警告のダイアログが出る。受け入れると ~/.claude/settings.json の skipDangerousModePermissionPrompt が true になり、以降は出ない（もう一度出すにはそのキーを消すか false にする。ほかの設定ファイルで組織が設定できる）。断ると Claude Code は終了する
• 非対話モードにダイアログは出ない。--bg で始めるバックグラウンドセッションは、対話セッションでダイアログを受け入れるまで拒否される
• Linux と macOS では、root か sudo で動かしていると起動を拒否する。メッセージは --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons。認識されたサンドボックス内ではこの検査は自動で飛ばされる。コンテナで自律的に動かすには、非 root ユーザーで動く開発コンテナの設定を使う
• クラウドセッションは、設定ファイルの defaultMode: "bypassPermissions" と "dontAsk" を認めない。リポジトリにチェックインされた設定でバイパスのクラウドセッションを始められないようにするため。設定は黙って無視され、セッションはモードのドロップダウンに出ているモードで始まる

保護されたパス#

少数のパスへの書き込みは、bypassPermissions と、bypass が使える対話端末のプランモード以外では、自動承認されません。リポジトリの状態や Claude 自身の設定が、うっかり壊れるのを防ぐためです。

• --restricted（v2.1.248 以降）で始めたセッションでは、分類器は保護されたパスへの書き込みを承認できない
• 保護されたパスの書き込みを分類器へ回すモードでも、シンボリックリンクの検査で保護されたパスに解決される書き込みは、要求されたパス自体が保護されていないとき、確認が出る
• 設定ファイルの permissions.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」

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

保護されたファイル：

重要なパス（critical path）#

重要なパスは、Claude Code が rm と rmdir から守るディレクトリです。ファイルシステムのルート、ホームディレクトリ、作業ディレクトリなどです。重要なパスを対象にした rm や rmdir は、permissions.allow ルールも、"allow" を返す PreToolUse フックも、ほかの確認を飛ばすモードでも承認できません。モデルの誤りへの安全弁で、一致する拒否ルールは引き続きコマンドを完全にブロックします。Remove-Item と cmd の削除の組み込みコマンドには別の検査があります（後述）。

重要なパスになるもの#

rm か rmdir の対象が次のどれかなら、重要なパスとして扱われます。

• ファイルシステムのルート
• ルート直下の最上位ディレクトリ（/usr・/etc・/data など）
• ホームディレクトリ
• Windows のドライブのルートとその最上位ディレクトリ（C:\ や C:\Windows）
• 作業ディレクトリとその親
• 追加の作業ディレクトリとその親。ただし、その下のグロブを削除するとき（rm -rf <dir>/*）だけ。ディレクトリ自体への rm -rf <dir> はこの検査の対象外

次の対象も重要なパスとして扱われます。

コマンド置換の出力だけを対象にした場合の検査を切るには、Claude Code を起動する環境で CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1 を設定します。

ネストしたコマンドとインラインスクリプトの中の削除#

• ネストしたコマンド：(...) のサブシェル、{ ...; } のブレースグループ、$(...) かバッククォートのコマンド置換、<(...) のプロセス置換。重要なパスの削除は、(rm -rf ~) や echo "$(rm -rf ~)" のようにネストした中にあっても、同じコマンドのほかの場所にあっても見つかる
• インラインスクリプト：bash -c 'rm -rf ~' のように、sh・bash・zsh など POSIX 系のシェルに -c で渡すスクリプト。二重引用符のスクリプトは、呼び出し側のシェルが変数を展開してから内側のシェルに渡されるので、find . -name '*.tmp' -exec sh -c "rm -rf \"$1\"/*" _ {} \; はマッチごとにルートからの削除に展開され、重要なパスの削除として扱われる。$1 に実際の値を束縛する単一引用符のスクリプト（sh -c 'rm -rf "$1"/*' _ {}）は対象にならない

-c のスクリプトに直接書いた重要なパス（~ など）の検査を切るには、Claude Code を起動する環境で CLAUDE_CODE_DISABLE_INLINE_SHELL_RM_PROMPT=1 を設定します。

指摘されたコマンドを書き直す#

変数の直下のグロブか末尾のスラッシュの確認は、指摘した rm を名指しし、検査を通る書き直し方を示します。

モードごとの重要なパスの削除の扱い#

• 明示的な ask ルールがそのコマンドに一致すれば、auto でも制限時間なしで確認される
• 確認が出るモードでは、PermissionRequest フックが確認に答えられる（フックのリファレンス）

auto と bypassPermissions では、端末での重要なパスの削除の確認に 2 分のカウントダウンが出ます。

• 答える前に時間が切れると、コマンドは拒否され、代わりにすることが Claude に伝えられるので、無人のセッションが進む
• 確認が開いている間に任意のキーを押すと、カウントダウンが止まり、答えを待ち続ける
• セッション中にこの確認が 3 回、無回答のまま切れると、以降は確認を出さず、重要なパスの削除を即座に拒否する。新しいメッセージを送ると数え直す
• auto で、端末の確認を出せない場所（-p の非対話の実行・Agent SDK のセッション・VS Code 拡張のチャットパネルとデスクトップアプリ）では、コマンドを即座に拒否する。拒否は、消そうとしたものを報告し、削除はあなたに任せるよう Claude に伝える
• auto と bypassPermissions のこの扱いは v2.1.281 以降が必要。切るには、CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1 を Claude Code を起動する環境に設定する。すると auto では重要なパスの削除が分類器に回り、bypassPermissions では確認に制限時間がなくなる

PowerShell の Remove-Item#

PowerShell ツールを有効にすると、Remove-Item と cmd の組み込みの rd・rmdir・del・erase には、rm の重要なパスの一覧とは別の検査がかかります。Remove-Item は対象で結果が変わり、最初に当てはまるものが適用されます。

• システムパスの検査は、Claude が cmd 経由で rd・rmdir・del・erase を動かす場合（cmd /c rd /s /q C:\Users）にも適用され、既定ではすべてのモードで確認なしに拒否する。この cmd の検査は v2.1.283 以降が必要
• cmd の対象を判断するとき、リテラルの文字の後ろの 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 を設定する。設定ファイルの env ブロックでは無視される。システムパスの Remove-Item は、どちらの場合も拒否されたまま

セキュリティの全体像はセキュリティとデータの扱い、非対話の実行はヘッドレス実行（-p）を参照してください。