Claude Code auto modeブロック一覧 — 既定で何を止めるか
Claude Codeのauto modeが既定でブロックする操作をカテゴリー別に一覧化。名指しで通る操作と、絶対に通らない操作の違いもまとめます。
Claude Codeのauto modeは、既定で30種類以上の操作カテゴリーをブロックします。対象はGit操作からクラウドインフラ、機密データの持ち出し、Claude自身の権限操作まで幅広く、「対象を名指しすれば通る操作」と「名指しでも絶対に通らない操作」がはっきり分かれています。auto modeそのものの全体像はClaude Code auto modeの中身にまとめています。本記事では具体的にどの操作がブロックされるかの一覧に絞ります。
auto modeが既定でブロックする操作とは
auto modeが無条件で自動承認するのは、読み取り専用の操作と作業ディレクトリ内のファイル編集だけです。それ以外の操作はすべて分類器という別モデルの判定を通ります。ブロックには2種類あり、soft_denyは対象を名指しした依頼があれば通り、hard_denyは名指しでも一切通りません。既定のhard_denyは機密データの外部送信を防ぐルール1つに限られていて、これから挙げるカテゴリーの大半はsoft_deny側です。つまり「一覧に載っている=絶対にできない」ではなく、「一覧に載っている=文脈を示さないと止まる」という読み方が正確です。
コード実行でブロックされる操作
公式ブロックリストの筆頭に挙がるのが、出所不明なコードのダウンロード実行です。curlでリモートのスクリプトを取得しそのままbashに渡すような操作は、対象URLを名指ししても分類器の判定対象になります。
Git・バージョン管理でブロックされる操作
Gitの操作は、取り返しがつくかどうかで扱いが分かれます。force pushやリモートの向き先変更は対象を名指しすれば通りますが、未コミットの変更を破棄する一連のコマンドはまとめてブロック対象です。
| 操作 | 補足 |
|---|---|
| force push | 補足対象ブランチを名指しすれば通る |
git reset --hard・git checkout -- .・git restore .・git clean -fd・git stash drop・git stash clear | 補足未コミットの変更を破棄する操作として一括りにブロック |
このセッションで作っていないコミットへのgit commit --amend | 補足セッション外で作られたコミットの書き換えを防ぐ |
既にpushされたコミットへのgit commit --amend(v2.1.198以降) | 補足メッセージのみの書き換え(--amend -m、新規ステージなし)は対象外 |
git remote set-url・git remote addによる向き先変更(v2.1.200以降) | 補足新しいリモートを名指しすれば通る |
別リポジトリ・別組織へのPR、gh repo fork、サードパーティへのpush(v2.1.200以降) | 補足対象を名指しすれば通る |
git commit --amendの判定がひとつの区分では終わらないのは、Claudeが自分で作ったコミットかどうかを見ているためです。セッション内で作ったコミットのメッセージだけを直す操作は、pushの有無にかかわらずブロック対象になりません。
クラウド・インフラでブロックされる操作
クラウド・インフラ系は既定のリストに含まれる項目とv2.1.195以降に追加された項目が混在します。後者の多くはenvironment設定で信頼済みの対象を登録しているかどうかが判定に関わり、社内ドメインやクラウドバケットの登録状況が判定の精度を左右します。
| 操作 | 補足 |
|---|---|
| 本番デプロイ・マイグレーション | 補足— |
| クラウドストレージの大量削除 | 補足— |
| IAMやリポジトリ権限の付与 | 補足— |
| 共有インフラの変更 | 補足— |
APIベースURL・プロキシ・webhook受信先・レジストリミラーの第三者ホストへの向け直し(.env.exampleも対象、v2.1.200以降) | 補足git remote set-urlの向き先変更ルールとは別枠。対象を名指しすれば通る |
terraform destroy・pulumi destroy・cdk destroy・terragrunt destroy、破壊的なplanの適用 | 補足— |
| シークレットマネージャーへの書き込み、DNS・TLS証明書の変更(v2.1.195以降) | 補足environmentの保護対象IaCスコープに連動 |
| 本番のフィーチャーフラグの切り替え・段階展開・削除(v2.1.195以降) | 補足— |
| 保護対象IaCスコープへの変更、クラスターノードのdrain・削除(v2.1.195以降) | 補足— |
| 名指しの範囲を超えて他ユーザーのジョブに及ぶ共有計算クラスターへの書き込み(v2.1.195以降) | 補足ラベルセレクタや--allが対象 |
| 全ノードで動くDaemonSetやトラフィックを横取りするadmission webhookの作成(v2.1.195以降) | 補足— |
| 機密性の高い接続先への対話シェル・ポートフォワード(v2.1.195以降) | 補足— |
| ローカルサービスを外部公開するトンネル・リバースシェルの開放(v2.1.195以降) | 補足— |
CI・プルリクエストでブロックされる操作
CIとPRのカテゴリーは、Claude自身が承認プロセスを迂回する経路をふさぐ目的でそろっています。
| 操作 | 補足 |
|---|---|
| 人間の承認を経ていないPRのマージ | 補足— |
| Claude自身が出したPRへの自己承認 | 補足— |
| CIチェックの無効化 | 補足— |
| 認証・アクセス制御・入力検証・サンドボックスを守るテスト/アサーションのコメントアウト・削除・強制通過(v2.1.200以降) | 補足セキュリティ関連のテストを無力化する変更として扱われる |
atlantis applyやbotの/deploy・/mergeのような、自動化への命令になるコメント投稿 | 補足コメント自体が実行トリガーになるため |
機密データ・認証情報でブロックされる操作
このカテゴリーはv2.1.198からv2.1.203にかけて段階的に強化されてきました。共通するのは「出典と送信先を両方名指ししない限り止める」という判定パターンで、自組織の公開リポジトリであっても例外にはなりません。
| 操作 | 補足 |
|---|---|
| デプロイの公開範囲を広げる、またはCIワークフロー・デプロイ設定を通じて秘密情報を外部に渡すコミット・push | 補足実行時の効果まで含めて判定。公開リポジトリでも適用 |
environmentで機密データ保管場所に指定した場所へのアクセス・持ち出し | 補足v2.1.198以降は除外先への送信も対象 |
| 内部パッケージレジストリを迂回した公開レジストリへのインストール | 補足v2.1.198以降は会話内で内部レジストリの存在を伝えただけでも対象 |
| SSHキー・クラウド認証情報・ブラウザプロファイル・シェル履歴などローカルの機微情報がコミットやgistに載る操作(v2.1.203以降) | 補足出典と送信先を両方名指しすれば通る |
| PR・issue本文、コミットメッセージ、コメント経由での機密情報流出(v2.1.198〜v2.1.203で段階強化) | 補足実在するメールアドレスやアカウントIDはv2.1.203以降、送信先の明示が必須 |
| 公開と分かっているリポジトリへの秘密情報・個人データのpush(v2.1.203で精緻化) | 補足dotfilesリポジトリのみ例外 |
| 認証情報やトークンをトランスクリプトやファイルにそのまま出力する操作 | 補足— |
| Claude in Chromeでのオフオリジンへのページ内容・Cookie・認証情報の送信(v2.1.195以降) | 補足信頼済みの内部ドメイン・localhost・名指ししたURLへのナビゲーションは既定で許可 |
セッション自身の制御・エージェント実行に関わる操作
このカテゴリーだけは対象がインフラやデータではなく、Claude Code自身の権限や監視の仕組みです。自分の承認プロセスを弱める行為はまとめて止まります。
| 操作 | 補足 |
|---|---|
--dangerously-skip-permissionsや--no-sandboxのような、承認もサンドボックスも経ずに動く自律ループの起動 | 補足v2.1.198以降は分離・個別承認を無効化したサードパーティのagent・evalハーネス実行も対象 |
--insecureのような安全機構を無効化するフラグ付きコマンド | 補足— |
| Claude Code自身のtmuxペインへのキー送信 | 補足自分自身の権限や監視を変更する行為として扱われる |
セッショントランスクリプト(~/.claude/projects/配下の.jsonl)への書き込み(v2.1.205以降) | 補足読み取りは対象外 |
ファイル削除でブロックされる操作
ファイル削除のうち、セッション開始前から存在したファイルの不可逆な削除と、対象を特定できない削除の2系統がここに含まれます。ファイルシステムのルートやホームディレクトリを狙う削除は、この区分とは別にどのモードでも止まる扱いなので後述します。
| 操作 | 補足 |
|---|---|
| セッション開始前から存在したファイルの不可逆な削除 | 補足— |
/tmpや$TMPDIRなど共有の一時ディレクトリへの、ワイルドカード・glob・経過時間指定による削除(v2.1.198以降) | 補足具体パス指定の削除は対象外 |
会話内で値を確認できないシェル変数を対象にしたrm -rf "$VAR"(v2.1.205以降) | 補足解決済みの絶対パスを書き直せば分類器を再度通せる |
| Claude自身がセッション中に作っていないステートフルリソースの削除(v2.1.200以降) | 補足対象を名指しすれば通る |
どのモードでも例外なく止まる操作
ここまでの一覧はauto mode中のsoft_denyが中心で、名指しの依頼があれば通ります。一方でClaude Codeには、権限モードに関係なく常に確認を挟む操作が別枠であります。bypassPermissionsモードでさえ対象になるものがあります。
- 明示的なaskルールに一致するツール
- 組織が
askに設定したコネクターツール AskUserQuestionツールと、requiresUserInteractionを指定したMCPツール- クリティカルパス(作業ディレクトリとその親ディレクトリ、ファイルシステムのルート、トップレベルディレクトリ、ホームディレクトリなど。
.claude/worktrees配下は除く)を狙ったrm・rmdir - セッション間メッセージングのセーフガード
クリティカルパスへのrm・rmdirは、allowルールやPreToolUseフックの"allow"では承認されません。ただしautoモードでは分類器の判定に回るため、文脈次第で承認されることがあります。allowルール・フックとautoモードの分類器は別の仕組みという点が、ここでの「無条件で止まる」の正確な意味です。
プロテクテッドパスへの書き込みも同様に扱いが特別です。対象は.git・.claude・.vscode・.husky・.cargoといったディレクトリです。ほかに.gitconfig・.bashrc・.npmrc・.mcp.jsonのような設定ファイルも含まれます。
| モード | 挙動 |
|---|---|
default・acceptEdits | 挙動プロンプトで確認 |
auto | 挙動分類器の判定に回る |
plan | 挙動編集そのものが発生しないため書き込みは起きない |
dontAsk | 挙動拒否される |
bypassPermissions(および同権限が使えるプランニングセッション) | 挙動無条件で通る |
allowルールでEdit(.claude/**)のように書いても、この判定はallowルールの評価より先に走るため効きません。個人・チーム・組織それぞれで権限モードをどう選ぶかはClaude Codeセキュリティ・権限ガイドにまとめています。
PowerShellのRemove-Itemはさらに厳格な判定になる
PowerShellツールを有効にしている場合、Remove-Itemはrmのクリティカルパス判定とは別の基準で扱われます。ファイルシステムのルート・ドライブルート・ホームディレクトリを狙うRemove-Itemは、モードを問わず分類器を経由せずそのまま拒否されます。*や/*・\*で終わるワイルドカード指定も同様に、分類器へ渡る前に拒否されます。対象が作業ディレクトリかその親で-Recurseが付いている場合だけは、その権限モードの通常の承認フローに乗ります。autoモードでは分類器の判定に回り、bypassPermissionsモードではこのチェック自体がスキップされます。
既定で許可される操作(対比)
すべてが慎重に扱われるわけではありません。次の操作は分類器を経由せず、あるいは分類器が既定で許可します。
- 作業ディレクトリ内のローカルファイル操作
- lockfileやマニフェストに書かれた依存関係のインストール
.envの読み取りと、対応するAPIへの認証情報の送信- 読み取り専用のHTTPリクエスト
- 作業中リポジトリの任意のブランチへのpush(デフォルトブランチを含む。
productionやgh-pagesのようなデプロイ先を示す名前のブランチは対象外で、別途判定される) - このセッションでClaudeが作った直後のジョブの削除(v2.1.195以降)
- タスクの一環としてのセキュリティ関連コード・設定・脅威モデルの読み書き(v2.1.195以降)
- マルチエージェントセッション内でのエージェント間メッセージ(v2.1.195以降。v2.1.222以降は
SendMessageが送信前に分類器のレビューを通る) environmentに登録した信頼済みドメイン・バケット・サービスへのデータ送信(データの流れのみが対象で、破壊的操作や認証情報操作は別扱い)
pushの許可範囲は段階的に広がってきました。v2.1.203より前はデフォルトブランチへの直接pushが一律ブロックでした。v2.1.211より前は、開始したブランチとClaude自身が作ったブランチ、デフォルトブランチへのルーチンpushだけが許可対象でした。今のように任意のブランチへのpushが既定で通るようになったのはv2.1.211からです。
名指しすれば通る操作と、絶対に通らない操作の見分け方
一覧の大半に「対象を名指しすれば通る」という補足が付いているのは、それがsoft_denyの性質だからです。「ブランチを整理して」のような曖昧な指示は通りませんが、「featureブランチをforce pushして」のように操作と対象を具体的に名指しした依頼は通ります。hard_denyに分類されるのは機密データの外部送信を防ぐルール1つだけなので、上の一覧のほとんどは文脈次第で実行可能です。例外はクリティカルパスへのrm・rmdirで、allowルールやPreToolUseフックでは覆りません。ただしautoモードでは分類器の判定に回るため、そこで承認される余地は残ります。実際に効いているルールを確認したいときは、次のコマンドで一覧をJSONとして出力できます。
claude auto-mode defaultsよくある質問
一覧にある操作をどうしても自動で通したいときは
autoMode.hard_deny・autoMode.soft_deny・autoMode.allowは独自ルールを足せます。"$defaults"を含めたまま書けば、既定を保ったまま範囲を広げられます。設定の詳細はClaude Codeのauto mode分類器は何を止めているかにまとめています。
この一覧に載っていない操作は無条件で通りますか
いいえ。一覧にない操作でも、会話の中であなたが示した境界(「pushしないで」など)は分類器がブロック信号として扱います。また分類器が安全性を判定できず処理そのものが失敗するケースもあり、これは一覧のブロックとは別のエラーとして扱われます。詳しくはClaude Codeのauto mode安全性判断エラーで扱っています。
プロテクテッドパスとクリティカルパスは同じものですか
異なります。プロテクテッドパスは.gitや.claudeなど設定ファイル向けの書き込み制限で、モードによっては分類器の判定を経て通ることがあります。クリティカルパスはrm・rmdirによるファイルシステムルートやホームディレクトリの削除を指し、allowルールでも一切覆せない点が最も厳格です。
このブロック一覧はどこで確認できますか
claude auto-mode defaultsを実行すると、有効なルール一覧がJSONで出力されます。実際にブロックされた操作の履歴は/permissionsの「最近の拒否」タブから確認できます。使い方はClaude Codeの/permissionsコマンドにまとめています。
まとめ
Claude Codeのauto modeは、コード実行からGit操作、クラウドインフラ、機密データの持ち出し、Claude自身の権限操作まで広い範囲を既定でブロックします。大半は名指しの依頼で覆るsoft_denyですが、クリティカルパスへの削除はallowルールやフックでは覆らず、autoモードの分類器判定に委ねられます。プロテクテッドパスへの書き込みも、bypassPermissionsモード(および同権限のプランニングセッション)以外では常に確認が挟まります。個別の判定ルールを書き換えたい場合は"$defaults"を保ったまま追加し、claude auto-mode defaultsで実際の設定を確認するのが安全です。