この記事の実施記録: Claude Codeで、進行管理役のエージェントが自分自身の行動規範ファイルを編集しようとしたところ、permission mode（実行モードという枠組み）の一状態であるauto modeの中で働く判定機構にブロックされた。エラーメッセージは「権限ルールを足せば解決する」と案内したが、.claude/settings.local.json の許可リスト（調査時点で577件）にはすでに該当ルールが入っていた。担当を別のエージェントに委任しても同じくブロックされ、最終的に解決したのは権限設定の追加ではなく、permission modeをauto modeから切り替える操作だった。
発端: 自分のルールを、自分で書き換えようとしたら
Claude Codeでは、役割ごとに複数のエージェントに作業を分担させて動かすことができる。今回問題が起きたのは、全体の進行を管理する役のエージェントが、自分自身の行動規範を定めたファイル（.claude/rules/ 配下にある、いわば運用マニュアル）を編集しようとしたときだった。同じ内容の追記でも、プロジェクトルートの CLAUDE.md への追記は通っていたが、.claude/rules/ 配下の個別ファイルへの編集だけがブロックされた。
ここで用語を整理しておく。Claude Codeのセッションには、実行モードの枠組みとして permission mode という仕組みがあり、auto mode はそのうちの一状態にあたる（人が都度の実行確認をしなくても、エージェントが自律的に操作を進められるモード）。今回ブロックしたのは auto mode という状態そのものではなく、auto mode の中で個々の操作の可否を判定している別の仕組みだった。この記事では以下、この仕組みを「判定機構」と呼ぶ。つまり permission mode（枠組み）→ auto mode（その一状態）→ 判定機構（auto modeの中で働く判定の仕組み）という包含関係になる。
「AIエージェントが、自分を縛るルールを自分で書き換えられてしまうのは不便では？」と思うかもしれない。実際不便ではあるが、ブロックの理由自体は妥当だと私は解釈している。AIが自分の行動規範を自分で書き換える操作に、通常より慎重なガードがかかるのは設計として健全だ。問題は「ブロックされたこと」ではなく、この後に書く「エラーメッセージの案内が、実態と合っていなかったこと」にあった。
Step 1: エラーメッセージの案内に従ってみる
ブロックされたときに表示されたエラーメッセージには、次の一文が添えられていた。
To allow this type of action in the future, the user can add a Bash permission rule to their settings.
素直に読めば「権限設定に該当ルールを足せば解決する」という案内だ。まずはこれを検証することから始めた。
Step 2: 権限設定を確認する → すでに許可されていた
ルールを足す前に、現状の権限設定を確認した。.claude/settings.local.json の permissions を数えてみると、allow（許可ルール）は調査時点で577件あり、このうち Edit(.claude/**) が既に含まれていた。ask（都度確認）は0件、deny（明示的な拒否）も0件だった。つまり許可はとっくに出ていた。それでもブロックされていた。
「これはバグでは？」という疑いも浮かぶが、私はバグというより設計の話だと考えている。ブロックそのものが誤動作だったわけではなく、エラーメッセージの案内文言（権限ルールを足せば直る）が実態と合っていなかっただけだ。案内を鵜呑みにして権限を足していたら、時間だけを使うところだった。
Step 3: 担当を替えてみる → それでもブロックされた
権限設定をいじっても意味がないなら、次に疑ったのは「誰が実行するか」だった。進行管理役のエージェント自身の操作ではなく、権限管理やインフラまわりの設定を担当する別のエージェントに、同じファイル編集を委任してみた。
結果は同じくブロック。担当を替えても通らなかった。
Step 4: permission modeを切り替える → 一度で成功
最後に試したのが、権限設定の中身をいじる方向ではなく、セッションが持つ実行モード（permission mode）自体を、auto modeから別のモードへ切り替える操作だった。切り替えには Shift+Tab を使い、モードを移してから同じ編集を実行したところ、一度で成功した。ただしこれは1回の観測にとどまり、同じ条件で繰り返し試して再現性を確かめたわけではない。
つまり .claude/settings.local.json の許可リストと、セッションのpermission modeは別々の仕組みとして動いている。今回のブロックは許可リストではなく、auto mode側の判定機構によるものだった。設定ファイルを1行も書き換えず、モードを切り替えるキー操作ひとつで通ったという事実が、両者が別レイヤーであることをそのまま示している。
自分の環境で確認する手順
同じように「許可されているはずなのに止められる」状況に遭遇したら、次の順で切り分けるとよい。
- 案内をそのまま実行する前に
.claude/settings.local.jsonのpermissions.allow/ask/denyを確認する - 該当ルールがすでに
allowにあれば、権限追加では解決しない - 実行主体（自分自身／別エージェントへの委任）を替えて再現するか確認する
- それでも変わらなければ、権限設定ではなくpermission mode側を疑い、
Shift+Tabでモードを切り替えて再試行する
auto modeでブロックされた3件に、共通点はあるのか
過去にも似た形でブロックされた記録が2件残っていた。1件は自動実行の登録作業を別のエージェントへ委任したときのブロック、もう1件はプルリクエストのマージ操作を委任プロンプトに含めたときのブロックだった。過去の2件はいずれも、チャットで事前に承認を伝えた上でブロックされている。今回は事前承認こそなかったが、権限設定側の許可はすでに出ていた。「先に許可や承認がある状態でも止められた」という点が、3件に共通している。
「3件並んだなら法則があるのでは？」と思うかもしれないが、断定はできない。委任先を替えてもブロックが外れないことを実際に確かめたのは今回のケースだけで、過去の2件は最初の委任がブロックされた時点で直接実行に切り替えており、別の委任先を試した記録は残っていない。3件を「担当を替えても通らない事例」として横並びに語ることはできない。
3件に共通するのは、自分自身の行動規範の書き換え・自動実行の登録・マージという、いずれも「一度実行すると後戻りが難しい、または実行主体の権限自体に関わる」種類の操作だったという点だ。ただし観測されたのはこの3件だけで、この判定機構が実際に何を見ているかは非公開・未確認である。傾向は見えるが、一般法則として書くことはできない。
ここから先は事実ではなく、私個人の現時点での見立てだ。「不可逆・自己言及的な操作ほど止められやすい」という傾向は、3件という少なさを差し引いてもそれなりに強いと私は感じている。もっとも、同種の操作が素通りする例か、逆に軽微な操作が止められる例がひとつ見つかれば、この見立てはあっさり崩れる。ルールを書いても機能するとは限らないという話は別記事でも22件の事故を分類して検証しており、今回はその延長線上にある。
これは、もう一つの「隠れた制約」と同じ話なのか
同じ日に、別の話も見つかっていた。Claude Codeのシステムプロンプトに、特定のモデル判定によって特定の指示文が注入されることがある、という話だ（詳細は別記事にまとめる予定）。
「もう一本の記事と同じ話では？」と思うかもしれないが、違う。あちらはシステムプロンプトへの指示文注入、こちらはauto mode側の判定機構という、技術的には無関係な別の機構だ。共通するのは「設定ファイルを読んだだけでは挙動のすべてが説明できるわけではない」という構造だけであり、両者を「隠れた制約」として一括りには語れない。
まとめ
許可リストに該当ルールがあっても、担当を替えても、それだけでは解決しない制約が存在する。今回効いたのは権限設定の追加ではなく、permission modeの切り替えだった。判定機構が何を見ているかは非公開で、確認できたのは「3件のうち、委任先を替えて確かめたのは1件だけ」という限定的な事実にとどまる。
同種のブロックに遭遇したら、案内文言をそのまま実行する前に許可リストの中身を確認し、それでも解決しなければpermission mode側を疑う——この切り分け順序を、次に同じことが起きたときの手順として持っておきたい。この判定基準がいつか公式に説明される日が来れば、あらためて書き直す。
許可リストとpermission modeが別レイヤーで動いているとわかると、次に浮かぶのは「権限やルールの仕組み全体は、どう設計すればいいのか」という問いだ。CLAUDE.md・サブエージェント・スキル・Playbook・メモリ・設定と権限・MCPという7つの部品に分けて整理したのがZenn Book『コードを書けない私がClaude Codeに「仕組み」を渡すまで』（序章無料）。
関連記事
- CLAUDE.mdは書いても守られない——ルールが効かなくなる3つの理由と、22件の事故から学んだハーネスエンジニアリング
- Claude Code 憲法続編：16日後、私が書いた法律に、私が殴られていた
- Claude Code の憲法を書いたら、1日で法律になった話
- Claude Code ToolSearch実践ガイド——公式ドキュメントにない4つの挙動
この記事は はてなブログ からのクロスポストです。