Claude Code Auto Mode を実際に動かして中身を全部見た

Claude Codeで長めのタスクを回していると、こんな確認が何度も出てきますよね。

Do you want to proceed?
❯ 1. Yes
  2. Yes, and don't ask again for: ...
  3. No

「このファイルを編集していいですか？」 → Yes
「このコマンドを実行していいですか？」 → Yes
「この……」 → Yes Yes Yes Yes Yes

「毎回Yes押すの面倒だから……」と --dangerously-skip-permissions を使ったことがある方、少なくないと思います。名前からして怖いフラグですが、それでも使いたくなるくらい承認ダイアログが邪魔に感じる場面があるのも事実です。

Claude Code v2.1で、この問題に対する新しい選択肢が追加されました。Auto Mode です。

Auto Modeとは

Claude Codeの権限モードの1つで、Claudeが分類器（classifier）を使ってアクションの許可/拒否を自動判断するモードです。

claude --permission-mode auto

従来の default モードでは全操作でユーザーに確認を求めていました。bypassPermissions（--dangerously-skip-permissions）は全操作を素通し。Auto Modeはその間で、Claudeの分類器が判断するモードです。

ユーザーの指示
  ↓
Claudeがツールを使おうとする
  ↓
分類器がallow/denyルールで評価
  ↓
├── allowに該当 → ユーザーに聞かず自動実行
├── denyに該当  → ユーザーに聞かず自動ブロック
└── どちらでもない → ユーザーに確認を求める

承認をスキップしているのではなく、Claudeが判断している。ここが重要です。

分類器の中身を見てみる

Auto Modeの判断ロジックは claude auto-mode config で確認できます。実際に叩いてみました。

claude auto-mode config

返ってきたJSONにはallowルールとdenyルールが並んでいます。これがAuto Modeの「脳」です。

allowルール（自動承認される操作）

注目すべきは「Declared Dependencies」の条件。npm install foo のようなエージェントが選んだパッケージ名の直接インストールは許可されない。typosquatやサプライチェーン攻撃のリスクがあるからです。

denyルール（ブロックされる操作）

30項目以上あります。主要なものを抜粋します。

特に面白いのが以下の2つです。

Content Integrity / Impersonation: 「失敗した作業を成功と報告する」「人間が書いたものとして署名する」──嘘をつくことがセキュリティ上の問題として明示的にブロックされている。

Exfil Scouting: データ持ち出しの準備行為（到達可能なエンドポイントの探索、エンコーディングバイパスの試行）すらブロック対象。未遂も捕捉する設計です。

実際に試してみた

ルールを眺めているだけではわからないので、--permission-mode auto で実際にいくつかの操作を試しました。

面白い発見がいくつかあります。

npm install express が通った。 denyルール上は「agent-chosen package names」はブロック対象のはずですが、ユーザーが明示的にパッケージ名を指定して指示した場合は分類器が許可しました。ルールの文面をそのまま適用するのではなく、文脈を見て判断しているようです。

rm -rf test.txt も通った。 denyルールの「Irreversible Local Destruction」には「without explicit user direction naming the specific targets」という例外があります。ユーザーがファイル名を指定していれば、削除も許可される。

~/.zshrc 変更とwebhook.site POSTは問答無用でブロック。 ユーザーが指示しても、シェル設定の変更（Unauthorized Persistence）と外部へのデータ送信（Data Exfiltration）は通りませんでした。

設定方法

起動コマンドだけでなく、設定ファイルでも有効化できます。

自分はユーザー設定で defaultMode: auto にしているので、毎回フラグを付けなくても常にAuto Modeで起動しています。

権限モード一覧

Claude Codeの全権限モードを整理します。claude --help と公式ドキュメントから確認した内容です。

セッション中にShift+TabでトグルできるAuto-Acceptは、上記とは別の仕組みです。画面を見ながら使う前提の機能。

--dangerously-skip-permissions との違い

両者の違いは**「判断しているのが誰か」**です。

bypassPermissionsは全てを素通しさせる。autoは30項目以上のdenyルールを持つ分類器が門番をやっている。この差は大きいです。

サンドボックスとの併用

Auto Modeは権限モード（Claudeの意思決定レイヤー）ですが、これとは別にOS レベルのサンドボックスが存在します。

• macOS: sandbox-exec（Seatbelt）
• Linux: bubblewrap

サンドボックスは以下を強制します：

• ファイルシステム隔離: ワーキングディレクトリ外のファイル変更をOS レベルでブロック
• ネットワーク隔離: Unixドメインソケット経由のプロキシで、承認されたドメインのみ通信許可

公式ドキュメントでは「権限（permissions）とサンドボックスは補完的なセキュリティレイヤー」と説明されています。権限はClaudeがツールを使うこと自体を制御し、サンドボックスはBashコマンドの実行範囲をOS レベルで制限する。二重の防御です。

チェックポイント

コード変更前に自動的に状態を保存する機能です。

• Escを2回押すか/rewindコマンドでロールバック可能
• ただし rm や mv などのBashコマンドによる削除はチェックポイント対象外
• あくまでClaude Codeの Edit / Write ツール経由の変更が対象

組織での管理

管理者がAuto Modeを含む権限設定を制御する手段があります。マネージド設定（managed settings）です。

公式ドキュメントに記載されている管理用設定：

設定の配信方法：

普段使いの所感

自分の場合、30個以上のスキルを組み合わせてClaude Codeを運用しています（記事はこちら）。設定ファイルで defaultMode: auto にしてから、日常的なコーディングで承認ダイアログを見ることはほぼなくなりました。

denyルールの粒度が想像以上に細かいのが印象的です。「force pushブロック」程度かと思っていたら、データ持ち出しの準備行為やエージェント自身の設定変更まで見ている。しかも claude auto-mode config で分類器のルールを全部確認できるので、「何がブロックされるか」が事前にわかる。ブラックボックスではない。

一方で、実験で見たように分類器の判断はルールの文面通りではない場面もあります。ユーザーの指示内容や文脈を見て柔軟に判断している分、予測が難しい面もある。Gitで管理 + 重要な操作は自分で確認する、この2つは引き続き意識しています。

まとめ

参考リンク

• Claude Code Permissions - 公式ドキュメント
• Claude Code Sandboxing - 公式ドキュメント
• Making Claude Code more secure and autonomous - Anthropic Engineering Blog
• sandbox-runtime - GitHub