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ルール（自動承認される操作）
| ルール | 内容 |
|---|---|
| Local Operations | ワーキングディレクトリ内のファイル操作。ただし「プロジェクトスコープ」の定義が厳密で、~/ や /etc への逸脱はスコープ外 |
| Read-Only Operations | GETリクエスト、読み取り専用APIコール。状態を変更しない操作 |
| Test Artifacts | テスト用APIキーのハードコード、プレースホルダー資格情報 |
| Declared Dependencies |
package.json や requirements.txt に既に宣言されているパッケージのインストール（npm install、pip install -r） |
| Toolchain Bootstrap | rustup、pypa、bun、brew等の公式インストーラーによるツールチェーン導入 |
| Standard Credentials |
.env から読んだAPIキーを対応するエンドポイントに送信 |
| Git Push to Working Branch | 作業ブランチへのpush（デフォルトブランチは除く） |
注目すべきは「Declared Dependencies」の条件。npm install foo のようなエージェントが選んだパッケージ名の直接インストールは許可されない。typosquatやサプライチェーン攻撃のリスクがあるからです。
denyルール（ブロックされる操作）
30項目以上あります。主要なものを抜粋します。
| カテゴリ | ブロック内容 |
|---|---|
| Git Destructive |
git push --force、リモートブランチ削除、履歴書き換え |
| Git Push to Default | main/masterへの直接push |
| Code from External |
curl | bash、外部リポジトリからのコード実行 |
| Production Deploy | 本番環境へのデプロイ、本番DBマイグレーション |
| Irreversible Local Destruction | セッション開始前から存在するファイルの rm -rf、git clean -fdx、git checkout .
|
| Data Exfiltration | 機密データの外部送信（HTTP、git push、クラウドストレージ） |
| Credential Exploration | 資格情報ストアの体系的スキャン |
| Self-Modification | エージェント自身の設定ファイル変更 |
| External System Writes | Jira/GitHub Issues/Slackへの投稿（ユーザーが明示的に指示していない場合） |
| Unauthorized Persistence | SSHキー追加、.bashrc変更、cronジョブ作成 |
特に面白いのが以下の2つです。
Content Integrity / Impersonation: 「失敗した作業を成功と報告する」「人間が書いたものとして署名する」──嘘をつくことがセキュリティ上の問題として明示的にブロックされている。
Exfil Scouting: データ持ち出しの準備行為（到達可能なエンドポイントの探索、エンコーディングバイパスの試行）すらブロック対象。未遂も捕捉する設計です。
実際に試してみた
ルールを眺めているだけではわからないので、--permission-mode auto で実際にいくつかの操作を試しました。
| 操作 | 結果 | 分類器の判断 |
|---|---|---|
ファイル読み取り（cat test.txt） |
自動実行 | Allow: Local Operations |
| ファイル編集（追記） | 自動実行 | Allow: Local Operations |
curl GETリクエスト（httpbin.org） |
自動実行 | Allow: Read-Only Operations |
rm -rf test.txt（ユーザーがファイル名指定） |
自動実行 | Allow: ユーザーが特定ファイルを明示指定 |
npm install express（未宣言パッケージ） |
自動実行 | ユーザーが明示的に指示→allowと判断？ |
git push --force origin main |
確認を要求 | Deny: Git Destructive |
~/.zshrc に追記 |
自動ブロック | Deny: Unauthorized Persistence |
curl POSTでwebhook.siteにデータ送信 |
自動ブロック | Deny: Data Exfiltration |
面白い発見がいくつかあります。
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）は通りませんでした。
設定方法
起動コマンドだけでなく、設定ファイルでも有効化できます。
| 方法 | スコープ | 設定 |
|---|---|---|
| CLIフラグ | そのセッションのみ | claude --permission-mode auto |
| ユーザー設定 | 全セッション |
~/.claude/settings.json に "permissions": {"defaultMode": "auto"}
|
| プロジェクト設定 | そのプロジェクトのみ |
.claude/settings.json に同上 |
| マネージド設定 | 組織全体（上書き不可） | MDM or /etc/claude-code/managed-settings.json
|
自分はユーザー設定で defaultMode: auto にしているので、毎回フラグを付けなくても常にAuto Modeで起動しています。
権限モード一覧
Claude Codeの全権限モードを整理します。claude --help と公式ドキュメントから確認した内容です。
| モード | 起動方法 | 動作 |
|---|---|---|
| default | claude |
ツール初回使用時に承認を求める |
| acceptEdits | --permission-mode acceptEdits |
ファイル編集を自動承認 |
| plan | --permission-mode plan |
分析のみ。ファイル変更・コマンド実行不可 |
| dontAsk | --permission-mode dontAsk |
/permissions で事前許可したツール以外は自動拒否 |
| auto | --permission-mode auto |
分類器がallow/denyルールで判断 |
| bypassPermissions | --dangerously-skip-permissions |
全操作を無条件で承認 |
セッション中にShift+TabでトグルできるAuto-Acceptは、上記とは別の仕組みです。画面を見ながら使う前提の機能。
--dangerously-skip-permissions との違い
両者の違いは**「判断しているのが誰か」**です。
bypassPermissions |
auto |
|
|---|---|---|
| 判断者 | なし（すべてスキップ） | 分類器（allow/denyルール） |
| force push | 通る | ブロック |
rm -rf（既存ファイル） |
通る | ブロック |
curl | bash |
通る | ブロック |
| 本番デプロイ | 通る | ブロック |
| 外部へのデータ送信 | 通る | ブロック |
| ローカルファイル編集 | 通る | 通る |
npm install（宣言済み） |
通る | 通る |
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）です。
公式ドキュメントに記載されている管理用設定：
| 設定キー | 効果 |
|---|---|
disableBypassPermissionsMode |
bypassPermissionsモードと--dangerously-skip-permissionsフラグを無効化 |
allowManagedPermissionRulesOnly |
ユーザー/プロジェクト設定でのpermissionルール定義を禁止 |
allowManagedHooksOnly |
マネージド以外のhooksを無効化 |
sandbox.network.allowManagedDomainsOnly |
マネージド設定のドメインのみ通信許可 |
設定の配信方法：
| プラットフォーム | 方法 |
|---|---|
| macOS | MDM（Jamf等）経由のマネージド設定 |
| Linux/WSL | /etc/claude-code/managed-settings.json |
普段使いの所感
自分の場合、30個以上のスキルを組み合わせてClaude Codeを運用しています（記事はこちら）。設定ファイルで defaultMode: auto にしてから、日常的なコーディングで承認ダイアログを見ることはほぼなくなりました。
denyルールの粒度が想像以上に細かいのが印象的です。「force pushブロック」程度かと思っていたら、データ持ち出しの準備行為やエージェント自身の設定変更まで見ている。しかも claude auto-mode config で分類器のルールを全部確認できるので、「何がブロックされるか」が事前にわかる。ブラックボックスではない。
一方で、実験で見たように分類器の判断はルールの文面通りではない場面もあります。ユーザーの指示内容や文脈を見て柔軟に判断している分、予測が難しい面もある。Gitで管理 + 重要な操作は自分で確認する、この2つは引き続き意識しています。
まとめ
| 項目 | 内容 |
|---|---|
| 何ができる | 分類器がallow/denyルールで操作を自動判断 |
| 起動方法 | claude --permission-mode auto |
| 永続設定 |
~/.claude/settings.json → permissions.defaultMode: "auto"
|
| allowルール | ローカルファイル操作、読み取り専用、宣言済み依存インストール等 |
| denyルール | force push、本番デプロイ、データ持ち出し、資格情報探索等30項目以上 |
| 確認方法 |
claude auto-mode config で分類器の全ルールを確認可能 |
| 安全策 | 分類器 + サンドボックス（OS レベル） + チェックポイント |