auto modeでCLAUDE.mdとhooksが無視される問題と回避策

サブディレクトリに置いたCLAUDE.mdや、.claude/rulesのパス限定ルールが効いていない気がする。そう感じたら、まずauto modeを疑う価値があります。auto modeのセッションでは、モデルと割り当てによって、ファイル操作をBashツール経由で行うよう誘導する指示がセッションのコンテキストに差し込まれます。この指示が、「CLAUDE.mdやルールはReadツールで読んだときに読み込まれる」という仕様とぶつかります。

GitHub issue #90450は2026年8月28日に報告されました。27通りのアクセス方法とパス限定ルールの実測、サブエージェントへの継承、実運用での漏れ率が積み上がっています。issueは開いたままで、9月30日にはClaude Code 2.1.286での再現も投稿されました。

なぜ入れ子のCLAUDE.mdと.claude/rulesが読み込まれなくなるのか

CLAUDE_CODE_THRIFTY_SONICという環境変数の値やバージョン別の挙動は、CLAUDE_CODE_THRIFTY_SONICとはで扱っています。ここでは、この指示がどの読み込み経路を止めているかを、ネストしたCLAUDE.mdとパス限定ルールに絞ってissueの計測結果から追います。auto mode自体を選択肢から消す設定は別物です。詳しくはClaude CodeのdisableAutoMode設定にまとめています。

issueの本文には、ライブセッションから抜き出したという指示文が逐語で引用されています。

Do your work through the Bash tool wherever it can accomplish the job: read files with cat, head, or sed -n, search with grep and find, and make file changes with sed, heredocs, or short scripts, rather than using the dedicated Read, Edit, or Write tools. Fall back to a dedicated tool only when Bash genuinely cannot do the job.

公式ドキュメントのCLAUDE.mdは、サブディレクトリのファイルを「Claudeがそのディレクトリのファイルを読んだときに読み込む」と説明します。ツールの種類は問わない書き方です。ところがissueの計測では、この「読む」を満たすのはReadツールだけでした。memoryのページにはauto modeへの言及がなく、衝突を予告する記述もありません。

auto-mode-configのページが書いているのは別の話です。分類器はClaude自身が読み込むのと同じCLAUDE.mdの内容を読む、という説明にとどまり、Bash優先の指示には触れていません。

memoryのページでReadが名指しされる箇所は、AGENTS.mdの節にあります。サブディレクトリのAGENTS.mdは「そのディレクトリのファイルをReadツールで開いたとき」に読み込まれる、という書き方です。CLAUDE.mdの説明は「ファイルを読んだとき」と曖昧なので、実装がReadツールに寄っていても、文面だけでは気づけません。

v2.1.283以降は入口が広がっている

permission-modesページによると、v2.1.283以降は、ターミナルとVS Codeの対話セッションでauto modeが開始時の既定モードです。それ以前はPro・Max・Teamプランに限られていました。つまり、自分でauto modeを選んだ覚えのない人のセッションも、この問題の入口に立っています。

ただしBash優先の指示が実際に付くかどうかは、モード名だけでは決まりません。次に見るモデルごとの割り当てと、issueで報告されたbypassPermissionsでの再現がその理由です。

auto modeを避けたいセッションでは、claude --permission-mode manualのように開始時のモードを指定できます。インストール済みのv2.1.287で--helpを見ると、選択肢は次のとおり表示されます。

claude --help | grep -A3 -e '--permission-mode'

  --permission-mode <mode>              Permission mode to use for the session
                                        (choices: "acceptEdits", "auto",
                                        "bypassPermissions", "manual",
                                        "dontAsk", "plan")

ドキュメント上、manualは設定値のdefaultと同じモードとされています。ただしこの方法は、Bash優先の指示と一緒にauto modeの分類器も手放す選択です。

27通りのアクセス方法を検証した結果 — Readツールだけが読み込む

issueの報告者は、一意のセンチネル文字列を仕込んだCLAUDE.mdを使い、27通りのアクセス方法をそれぞれ独立したディレクトリで検証しています。

auto modeの指示が名指しするcat・head・sed -n・grep・find・sed・heredocの7つの動詞は、すべてPOSIXシェルの行に含まれています。指示に忠実に従うほど、ネストしたCLAUDE.mdから遠ざかる構造です。

存在しないファイルへのRead呼び出しでも、ディレクトリのCLAUDE.mdは読み込まれたと報告されています。エラーは返しつつメモリは注入される挙動です。トリガーが実際の内容ではなく、Readツールのfile_path引数を解決した事実そのものだと確かめる根拠になっています。Grepツールがファイルの中身を返しながら何も注入しなかった結果も、内容がコンテキストに届くことがトリガーではないという反証です。

パス限定ルール(.claude/rules)にも同じ穴がある

.claude/rulesのパス限定ルールでも同じ検証が行われています。こちらは4パターンとも、陰性を確認したあとにReadで発火させ、ルールが生きていることを確かめる手順です。

パス限定ルールは、公式ドキュメントが「CLAUDE.mdが肥大化したときの対策」として案内している仕組みです。その対策自体がauto modeの下では効かなくなる点は、影響の大きさを見るうえで無視できません。ルールはルールごとにセッション中1回だけ読み込まれる仕様です。早い段階でReadによって一度発火したルールは、後から対象ファイルに触れても再度は主張されません。

この読み込みの失敗は、セッションの作業ディレクトリの内側に限られます。作業ディレクトリの外に置いたファイルでは、Read・Bashのどちらでアクセスしてもメモリは注入されなかったという追試結果があります。共有ルールを1階層上に置く運用では、この境界を踏まえておく必要があります。

EditやWriteに絞ったPreToolUse・PostToolUseフックのマッチャーが発火しなくなる副作用もあります。こちらはBash経由の編集そのものが原因の別系統の問題で、前述のCLAUDE_CODE_THRIFTY_SONICの記事で扱われています。

自分のセッションは影響を受けるのか

結論から言うと、モデルとセッションごとの割り当てで決まります。Bash優先の指示が付くかどうかは、セッションごとに1回だけ決まります。基準になるのは、トップレベルのセッションが使っているモデルです。次の表は、2.1.263のバンドルを解析した9月8日のコメントによる割り当てです。

ただし9月30日には、2.1.286のOpus 5.5(claude-opus-5-5)でも指示が付いたと報告されており、表にないモデルでも付かないとは言い切れません。

見落とされやすいのは、サブエージェントが親セッションの割り当てをそのまま引き継ぐ点です。CLAUDE_CODE_SUBAGENT_MODELでサブエージェントだけclaude-sonnet-5に切り替えても効果はありません。親セッションがforced割り当てのモデルであれば、そのサブエージェントもBash優先の指示を受け取ります。

レビュー役・計画役・実装役をサブエージェントに分けるマルチエージェント構成では、親が割り当て対象なら全員が同時にこの影響を受けます。親は各サブエージェントの要約しか見ないため、気づく手段も乏しくなります。

同じモデルでも、cohortの割り当て次第で結果が変わります。同じバージョン・同じモデルの2人が、違う挙動を見る可能性があります。

自分のセッションで確かめるには、次の手順が使えます。ログを取るフックと、遅延読み込みだけを拾うmatcherは、hooksドキュメントに載っています。合言葉とBash/Readの比較で確かめる組み立ては、9月23日のissueコメントの再現手順にならったものです。

トランスクリプトを直接読む方法もあります。issueのコメントによると、Claude Codeはルールの読み込みをトランスクリプトにnested_memoryという種類の添付データとして記録します。トランスクリプトの形式は公式には文書化されていないため、将来変わる可能性があります。

実際の編集作業でどれだけ起きているか

ここまでは意図的な再現実験でしたが、issueには実運用データも投稿されています。対象はGo製バックエンドとTypeScript/Vue製フロントエンドを持つ本番モノレポです。.claude/rulesに9本のパス限定ルールを運用した約3か月分、Claude Code 2.1.231〜2.1.282のセッションが対象になっています。

ファイルへのEdit・Writeごとに、対応するルールが事前に読み込まれていたかを突き合わせた集計です。対象セッションは主にbypassPermissionsモードで、一部はautoモードです。Bash優先の指示は両方のモードに現れるため、auto modeに限った現象ではないとも報告されています。

ルールが漏れていた変更を、対象ファイルをどう見ていたかで内訳を取ると、漏れの原因はほぼ一つに絞れます。

Readツールで読んだあとにルールが漏れていた変更は0件でした。ルール別の漏れ率は41%から81%まで幅があり、あるGo向けテストルールでは81%に達しています。この数字をもとに、ReadだけでなくEdit・Writeの対象パスにもpaths:条件を評価する変更案が、別issue(#38487)で提案されています。この実測データでは、その変更だけで漏れの526件すべてをカバーできたはずだとされています。

環境変数で指示を止めたとき、何が直り、何が残るか

CLAUDE_CODE_THRIFTY_SONICをfalseに設定すると、Bash優先の指示自体が挿入されなくなります。この動作は複数の利用者によって独立に確認されています。macOS・Windows・Linuxで再現し、settings.jsonのenvに書く方法が使われています。

{
  "env": {
    "CLAUDE_CODE_THRIFTY_SONIC": "false"
  }
}

この環境変数は公式の環境変数リファレンスには掲載されておらず、issueのコメントで見つかったものです。検証には、セッションのトランスクリプト(~/.claude/projects/**/<session-id>.jsonl)を使っています。記録されるauto_modeという種類の添付データを直接読む方法です。

grep -o '"type":"auto_mode"[^}]*}' ~/.claude/projects/*/*.jsonl | tail -1

この添付データにはbashFirstという真偽値とbashFirstSteerという強度の値が入っています。環境変数を設定していないセッションではbashFirst":trueが記録されます。CLAUDE_CODE_THRIFTY_SONIC=falseのセッションでは、添付データ自体が現れないと報告されています。

値の書き方については、9月30日の投稿が参考になります。Linuxでclaude -p --dangerously-skip-permissionsを使った計測では、falseでも0でも指示が外れたと報告されています。CLAUDE_CODE_THRIFTY_SONICとはで扱っている別のissueも"0"を使っており、どちらを選んでも、設定後にトランスクリプトで確認しておくと確実です。

同じ投稿は、変数が直すものと直さないものを分けて示しています。

効く場面とした「apps/web配下にヘルパーを足して」の依頼でも、読み込みは0/3から1/3に増えただけでした。指示文を外してもモデルが自分でBashを選ぶためで、読み込みの条件がReadの呼び出しである以上、完全な解決にはなりません。この投稿は、ローダー側がEdit・Writeの対象やBashによる読み取りにもpaths:を照合する修正が必要だと結論づけています。コメントでは、その提案として#93248が挙げられています。

tools-referenceには、もう一つ関連する記述があります。cat・head・tail・sed -n・grepなどで単一ファイルを見れば、Bashでもread-before-editの要件は満たされます。パイプやリダイレクトを含むコマンドは数えられません。Bashで読んだだけでもEditに進めるので、Editの前にReadを強いる力も働きません。新しいモデルでは、Readが権限プロンプトを要しない未読のファイルを、そのままEditできます(v2.1.208以降、Readツールが使える場合)。

もう一つの未文書化の変数にCLAUDE_CODE_COZY_TEAPOTがあり、strict(既定)とrelaxedを切り替えられます。ただしrelaxedは指示の言い回しを和らげるだけで、catやsed -nへ誘導する動詞自体は変わりません。衝突を解消するのはCLAUDE_CODE_THRIFTY_SONICだけだと結論づけられています。似た名前の公式変数にCLAUDE_CODE_AUTO_MODE_SERVERがありますが、こちらはサーバー側レビューを止めるための、まったく別の公式設定です。

環境変数の扱いにはもう一つ注意点があります。CLAUDE_CODE_THRIFTY_SONICは値が設定されているかどうかで判定されるため、明示的なfalseが意味を持ちます。一方で似た仕組みの姉妹変数の一部は、値の真偽だけを見て判定されます。falseを渡しても偽と評価されて既定値に落ちるとも指摘されており、同じ書き方がどの変数にも通用するとは限りません。

また、~/.claude/settings.jsonのユーザースコープに置くと、サブエージェントにも同じ設定が引き継がれます。

InstructionsLoadedとPreToolUseで漏れを補う

環境変数は原因の一部を止める設定です。実際にどのルールが読み込まれ、どれが漏れたかを確認する手段は別に必要です。公式のhooksドキュメントには、CLAUDE.mdや.claude/rulesが読み込まれるたびに発火するInstructionsLoadedイベントが用意されています。

load_reasonはsession_start・path_glob_match・nested_traversal・include・compactのいずれかです。matcherにはこの値を使い、遅延読み込みだけを対象にすることもできます。trigger_file_pathには、読み込みのきっかけになったファイルのパスが入ります。

{
  "hooks": {
    "InstructionsLoaded": [
      {
        "matcher": "path_glob_match|nested_traversal",
        "hooks": [
          { "type": "command", "command": "python3 ~/.claude/hooks/log-loaded.py" }
        ]
      }
    ]
  }
}

このイベントは決定や遮断を持たず、観測専用です。hooksのページでも、非同期に動く観測用のイベントとされています。hooksでテストを自動実行するで扱っているような他のフックと組み合わせれば活用の幅が広がります。

「ネストしたCLAUDE.mdがあるのに、一度もnested_traversalが記録されないままセッションが終わった」ことを、ログから発見できるようになります。ファイルをcatで開くたびに、記録が増えないことも確認できます。

では、漏れたルールを補うことはできるのでしょうか。issueのコメントには、PreToolUseフックにはadditionalContextが使えないため、フック側から差し戻すことはできないという説明がありました。ただし公式のhooksドキュメントでは、PreToolUseの出力フィールドにadditionalContextが載っています。ツールの結果と並べてClaudeのコンテキストに足される文字列、という説明です。

この機能はv2.1.9(2026年1月16日)で追加されました。v2.1.110(4月15日)には、ツール呼び出しが失敗したときに値が落ちる不具合の修正が入っています。

Bashのcatやsedの呼び出しをきっかけに、ネストしたCLAUDE.mdの中身をadditionalContextとして差し戻す設計は、記載上は成立しそうに見えます。ただしissueのスレッドでは、この構成を試した報告はまだありません。フックが足すのはシステムリマインダーとして挿入される文字列で、ルールファイルの読み込みそのものではありません。9月23日のコメントでも、フックからメモリの読み込みを起こせるようにする変更が要望として挙がっています。

10月1日のコメントで紹介されたPreToolUseフックは、Bashの書き込みを記録する監査用です。投稿者自身が、catで入れ子のCLAUDE.mdを読み込ませることはできないと明記しています。

最も確実なのは、守らせたい安全ルールを、起動時に必ず読み込まれるルート直下のCLAUDE.mdか、paths:の条件を持たない.claude/rulesのルールに置くことです。起動時に読まれるファイルは、Bash優先の指示の影響を受けません。

まとめ

原因は設定の誤りではなく、Bash優先の指示とReadツール限定の読み込み条件の食い違いです。CLAUDE_CODE_THRIFTY_SONIC=falseは指示を外します。ただ探してから読む作業では漏れが残るので、確実に守らせたいルールはルート直下のCLAUDE.mdへ移すのが安全です。InstructionsLoadedのログがあれば、漏れたセッションを後から特定できます。