Claude Code の auto mode に止められた操作を1か月分集計した（64件の内訳と、許可リストの落とし穴）

Claude Code の auto mode は、いちいち許可を求めずに作業を進めてくれるモードです。そのかわり、別のモデル（分類器）が操作を一つずつ見て、危ないものを止めます。止められると、Claude には [Production Deploy] のような理由付きのエラーが返ります。

普段使っていると「また止められた」という印象だけが残ります。そこで、実際に何回、何が止められたのか を会話ログから数えてみました。数えたあとで公式ドキュメントを読み直すと、自分の許可リストの運用にも勘違いが見つかりました。

※ 環境は Windows、Claude Code 2.1.296 です。止められた操作の多くは、個人で運用している Web サービスのものです。

集め方

Claude Code の会話ログは、~/.claude/projects/<プロジェクト>/<セッション>.jsonl に1行1件の JSON で残っています。拒否されたツール呼び出しには、次のような結果が記録されます。

Error: Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Self-Modification]. ...

この文言で始まるエラーを探し、tool_use_id で元のツール呼び出し（実行しようとしたコマンド）と突き合わせる Python スクリプトを書きました。ログは標準で30日ほどで消えるので、残っていたのは 2026年9月14日〜10月15日の約1か月分 です。

項目	件数
ツール呼び出しの総数	22,526
auto mode に拒否された	64（約0.3%）

拒否は思ったより少なく、350回に1回ほどでした。「よく止められる」という印象は、止められると作業が中断して記憶に残るせいだったようです。

何が止められたか

理由（角かっこの中のカテゴリ）別に数えると、次のとおりです。

カテゴリ	件数	主な中身
Production Deploy	24	Cloud Run・Cloud Functions・Cloudflare へのデプロイ、本番 DB のマイグレーション
Irreversible Local Destruction	8	生成物の一括 rm -rf、アンインストーラーの起動、バックアップからの上書き復元
Credential Materialization	8	アクセストークンを表示する、認証情報のファイルを cat する
Self-Modification	3	.claude/settings.local.json や ~/.claude.json の編集
その他（9種）	21	IAM のロール作成、Secret Manager への書き込み、DNS・固定 IP の変更、プロセスの強制終了など

止められたツールは、ほとんどが Bash（58件）でした。ファイルの編集（Write・Edit）は5件で、そのうち2件は Claude Code 自身の設定ファイルです。

止められて正解だったもの

中身を見ると、大半は止められて正解 でした。

• デプロイ：本番に出す前に自分で確認したかったものが多くあります。止められたあと、何をどこにデプロイするかまで具体的に伝えれば、その1回は通ります
• 認証情報の表示：トークンを確かめようとして print-access-token を実行するような操作です。トークンが会話ログに残ってしまうので、止めてもらったほうが安全です
• 一括削除：パターンに一致したファイルをまとめて rm -rf しようとした例がありました。消す対象が本当に正しいかは、人が見るべきところです

止める必要がなかったもの：読むだけの grep

一方で、意外なものも止められていました。読むだけのコマンド です。

grep -n "<サービス名>" <デプロイ手順の README> | head -8

これは、デプロイの手順を README から探しただけのコマンドです（パスやサービス名は伏せています）。これが [Production Deploy] で止められていました。同じように、grep や sed -n、tail で中身を見るだけのコマンドが、9件ほど拒否されています。

公式ドキュメントによると、分類器は コマンド単体ではなく、会話の流れも見て判断します。ユーザーの発言や、それまでのツール呼び出しも読んでいます。デプロイを止められた直後に、デプロイ方法を調べ始めた。そういう流れが、「止められた操作を別の方法でやろうとしている」と見えたのだと思います。

もう一つ、ドキュメントには「サーバー側で分類器がレビューするセッションでは、読み取りだけのコマンドもレビューを待ち、問題ありと判断されれば止められる」とも書かれています。普段は読み取りなら自動で通りますが、いつもそうとは限らないということです。

許可リストに足せば解決、とは限らない

私はグローバルの CLAUDE.md に、こんなルールを書いていました。

auto mode で止められたら、許可を得たうえで、そのコマンドのパターンを .claude/settings.local.json の permissions.allow に追記する

ところが、公式ドキュメントを読むと、このやり方には効く場合と効かない場合がありました。

効く：狭い許可ルール

auto mode では、操作は次の順で判断されます。

1. permissions の allow / ask / deny ルールに一致すれば、その場で決まる（分類器は見ない）
2. 読み取りと、作業ディレクトリ内のファイル編集は自動で許可
3. それ以外は分類器が判断する

Bash(gcloud run deploy *) のような許可ルールは1で決まるので、分類器に止められなくなります。実際に、デプロイを何度も止められたリポジトリでは、gcloud run * や npx wrangler deploy* を許可リストに足していました。

ただし、これは 分類器のチェックを外す ということです。ドキュメントにも「狭いルールでも、ルールが想定していない引数で破壊的な操作が通ることがある」と書かれています。たとえば Bash(sed *) を足すと、読むだけの sed -n だけでなく、ファイルを書き換える sed -i も素通りします。

効かない1：広すぎる許可ルール

auto mode に入ると、任意のコードを実行できる広い許可ルールは無効 になります。

• Bash(*)
• Bash(python*) のような、インタープリタのワイルドカード
• パッケージマネージャーの実行コマンド

私のグローバル設定には Bash(python *) や Bash(node *)、Bash(npx *) が入っていましたが、auto mode ではこれらは効いていません。auto mode を抜けると元に戻ります。

効かない2：Claude Code 自身の設定ファイル

.claude/ フォルダや .claude.json などは 保護されたパス で、ここへの書き込みは allow ルールがあっても分類器に回ります。拒否された「Self-Modification」の3件は、まさにこれでした。

つまり、「止められたら許可リストに足す」というルールそのものが、auto mode では止められやすい作業だったわけです。許可リストを足すときは、Claude に頼まず、自分で /permissions から追加するほうが確実です。

拒否を減らすための設定

ドキュメントには、許可リストのほかにも方法がありました。

方法	向いているもの
会話で「〇〇を△△にデプロイしてよい」と具体的に伝える	1回だけ通したい操作。動詞だけ（「デプロイしていいよ」）では足りず、対象まで書く必要がある
autoMode.environment に、信頼するリポジトリ・ドメイン・バケットなどを文章で書く	毎回同じ宛先で止められる場合
autoMode.allow に、許してよい操作を文章で書く	「ステージング環境へのデプロイはよい」のような、定型の例外
/permissions の Recently denied タブ	止められた操作を確認して、r で再試行する
/auto-mode-setup	最近のセッションから autoMode.environment の下書きを作ってもらう

注意点が2つあります。

• autoMode の設定は ~/.claude/settings.json に書く。プロジェクトの .claude/settings.json や settings.local.json に書いても読まれません（リポジトリ側から許可を注入できないようにするため）
• /auto-mode-setup は機能フラグの取得が必要です。前の記事 で書いた CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC を入れていると使えません。DISABLE_TELEMETRY でも機能フラグの取得は止まるので、同じく使えません

今の設定は claude auto-mode config で確認できます。既定のルールは claude auto-mode defaults で全文を読めます。

まとめ

• auto mode の拒否は、1か月で 64件、ツール呼び出しの約0.3% だった
• 半分近くは本番デプロイで、認証情報の表示や一括削除と合わせて、大半は止められて正解 だった
• 分類器は会話の流れも見るので、止められた直後の読むだけの grep も止められることがある
• 狭い allow ルールは分類器を通さずに許可するので効く。ただし、そのぶんチェックも外れる
• Bash(python *) のような広い allow ルールは、auto mode では無効になる
• .claude/ の設定ファイルは保護されたパスなので、Claude に許可リストを編集させると止められる
• 毎回同じ宛先で止められるなら、~/.claude/settings.json の autoMode.environment に書く

止められた操作を数えてみると、印象よりずっと少なく、しかも多くは自分で確認したいものでした。auto mode に止められるのは、確認を挟むべきところが分かるということでもあります。全部を許可リストで通すより、どこで止めてもらうかを自分で決めておくほうがよさそうです。