TL;DR

Claude Code の auto モードは「全許可スキップ」ではなく、別の分類器モデルが各アクションを実行前に審査 して危険なものだけブロックする仕組み。
git reset --hard や terraform destroy など 取り消し困難なコマンドは、セッション内で明示的に頼まない限りデフォルトでブロック される（一覧は本文）。
ブロックが 3回連続 or 累計20回 でauto modeは自動停止し手動承認に戻る（しきい値は変更不可）。
「絶対にやらせない」を固定したいなら会話中の口頭指示ではなく deny ルール で宣言する（口頭の境界はコンテキスト圧縮で消える）。

背景・課題

Claude Code を自動運転（auto mode）で回すと、承認プロンプトの嵐から解放される一方で「勝手に git reset --hard されたら？」という不安がつきまといます。実際、私も自動化パイプラインを組むたびに「どこまで信用していいのか」が一番の悩みでした。

結論から言うと、auto mode は --dangerously-skip-permissions（全スキップ）とはまったく別物で、3層の防御 が効いています。本記事では Claude Code 公式ドキュメント（permission-modes）の一次情報をもとに、その防御がどう働くかと、自分で固める設定を整理します。

前提: 6つの権限モードのどこに auto があるか

Claude Code の権限モードは6種類あり、「何が確認なしで実行されるか」で段階が分かれています。

モード	確認なしで実行される範囲	向いている場面
`default`	読み取りのみ	慎重な作業・はじめて
`acceptEdits`	読み取り＋ファイル編集＋ `mkdir`/`mv` 等	レビュー前提のコード反復
`plan`	読み取りのみ（編集せず計画）	変更前のコードベース調査
`auto`	すべて（バックグラウンド安全チェック付き）	長時間タスク・プロンプト疲れ対策
`dontAsk`	事前承認したツールのみ	ロックダウンしたCI
`bypassPermissions`	すべて（チェックなし）	隔離コンテナ/VM専用

bypassPermissions 以外のすべてのモードで、.git や .claude、.mcp.json といった「保護パス」への書き込みは自動承認されません。auto mode でも保護パスへの書き込みは分類器に回されます。

auto mode の利用には Claude Code v2.1.83 以降 が必要で、Team/Enterprise では管理者の有効化が前提です。

第1層: 分類器がデフォルトでブロックする破壊的コマンド

auto mode の核は、/model で選ぶモデルとは独立した サーバー側の分類器モデル です。これがすべてのシェルコマンド・ネットワーク操作を実行前に審査します。

公式ドキュメントが「デフォルトでブロック」と明記している主なアクションは次のとおりです。

curl | bash のようなコードのダウンロード実行
本番デプロイ・マイグレーション、クラウドストレージの大量削除
IAM やリポジトリ権限の付与、共有インフラの変更
force push、または main への直接 push
git reset --hard / git checkout -- . / git restore . / git clean -fd / git stash drop / git stash clear（未コミット変更を捨てると推定されるため・v2.1.183〜）
HEAD のコミットが当該セッションで作られたものでない場合の git commit --amend
terraform destroy / pulumi destroy / cdk destroy / terragrunt destroy、およびリソースを破壊する plan の適用

逆に、作業ディレクトリ内のローカル操作・lock ファイルに宣言済みの依存インストール・読み取り専用HTTP・開始ブランチへの push はデフォルトで許可されます。claude auto-mode defaults で全ルールを確認できます。

ポイントは「明示的に頼めば実行される」こと。git reset --hard を実行して と自分で指示すれば通りますが、Claude が自己判断で勝手に走らせることはブロックされます。

第2層: 暴走を止めるフォールバックと、auto移行時のルール剥奪

分類器が 3回連続、または累計20回 ブロックすると、auto mode は一時停止して手動承認モードに戻ります。このしきい値は 変更不可 で、-p（非対話）実行時は停止ではなくセッションを中断します。無限ループや予算浪費に対する安全弁です。

さらに見落とされがちなのが、auto mode に入った瞬間に「広すぎる許可ルール」が剥奪される 点です。

Bash(*) / PowerShell(*) のブランケット許可
Bash(python*) のようなワイルドカードのインタープリタ
パッケージマネージャの run コマンド、Agent の許可ルール

これらは auto mode 中だけ無効化され、Bash(npm test) のような 狭いルールはそのまま有効。auto mode を抜けると剥奪されたルールは復元されます。「全許可しておけば楽」が auto mode では通用しない設計です。

なお分類器が読むのは ユーザーメッセージ・ツール呼び出し・CLAUDE.md の内容 だけで、ツールの実行結果（ファイルやWebページの中身）は除去されます。読み込んだファイルに仕込まれた悪意あるテキストが分類器を直接操作できないようにするためです。

第3層: 「絶対やらせない」を固定する hard deny と deny ルール

会話中に「push しないで」と伝えると、分類器はそれを ブロック信号 として扱い、デフォルトでは許可される push も止めます。ただしこの口頭の境界は ルールとして保存されず、コンテキスト圧縮で当該メッセージが消えると失われます。

恒久的な保証が欲しいなら、deny ルールで宣言します。deny と explicit ask ルールは bypassPermissions を含むすべてのモードで効きます。

// .claude/settings.json
{
  "permissions": {
    "deny": [
      "Bash(git push:*)",
      "Bash(terraform destroy:*)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

組織全体で固定したい場合は managed settings で permissions.disableAutoMode を "disable" に設定すれば、ユーザーが auto mode を有効化できなくなります。

auto をデフォルトにするときの落とし穴

defaultMode: "auto" を .claude/settings.json（プロジェクト）や .claude/settings.local.json に書いても、v2.1.142 以降は無視されます。「リポジトリが自分自身に auto 権限を与える」ことを防ぐためで、auto を既定にするには ユーザー設定 ~/.claude/settings.json に書く必要があります。私は最初これに気づかず「設定したのに default で起動する」と数分溶かしました。

著者視点の発見ポイント

実際に auto mode で自動化を回して一番効いたのは、「広い許可ルールが自動で剥奪される」挙動 でした。bypassPermissions を避けて auto に寄せるだけで、Bash(*) のような雑な許可設定が事実上無効化され、破壊的コマンドだけが分類器で止まる——「楽をしたいのに安全側に倒れる」という珍しい設計になっています。

逆にハマったのは 口頭の境界が圧縮で消える 点です。長時間セッションで「本番には触らないで」と最初に言っても、圧縮後はその制約が分類器から見えなくなります。重要な禁止は最初から deny ルールに落とすのが正解で、「会話で伝えたから大丈夫」は危険だと実感しました。サブエージェントについても、起動前のタスク記述・実行中・完了時の3点 で分類器が審査する（起動前審査は v2.1.178〜）ため、子エージェント経由の抜け道も塞がれています。

まとめ

auto mode は分類器による 第1層（破壊的コマンドのデフォルトブロック）・第2層（3回/20回フォールバックと広い許可の剥奪）・第3層(hard deny/deny ルール) の多層防御。
「絶対やらせない」は会話ではなく deny ルールで固定する。
auto を既定にするならユーザー設定 ~/.claude/settings.json に書く。

承認の手間を減らしつつ事故を防ぐには、bypassPermissions ではなく auto mode + 明示的な deny ルールの組み合わせが現時点の最適解だと考えています。