Claude Code rulesがWriteの新規ファイルで読まれない問題と現状

.claude/rules/にpaths:付きのルールを書いたのに、Claudeが新しく作ったファイルには反映されていない。入れ子のCLAUDE.mdでも同じことが起きる。この症状はGitHub issue #96361で報告されています。先に現状を言うと、Write(ファイル新規作成)で読み込まれない件は、v2.1.288の修正で解消したと読めます。issue自体は開いたままで、Bashまわりに穴が残っています。

issue 96361は何を報告しているのか

issue #96361のタイトルは「Path-scoped rules and nested CLAUDE.md never load when Write creates a new file」です。2026年9月23日に起票され、Claude Code 2.1.280で確認された内容です。

主張は次の3点に絞れます。

• paths:付きのルールと入れ子のCLAUDE.mdは、一致するファイルをClaudeがReadしたときにだけ読み込まれる
• Writeで新規ファイルを作る場合は、どちらも読み込まれない
• エラーは出ず、失敗は静かに進む

既存ファイルへの上書きは、Writeが「先に読むこと」を求めるので、そのReadでルールが読まれます。穴になるのは新規ファイルだけです。そしてルールが最も必要なのは、まさにディレクトリへ新しいファイルを足す場面です。

報告者の再現環境は、空のgitリポジトリに次の3ファイルを置いたものです。

これを新しいclaude -pセッションごとに別々の操作で試し、セッション記録のうちハーネスが書いた記録で結果を判定しています。モデルの自己申告に頼っていない点が、この再現の強みです。

モデルに依存しない問題で、報告者はclaude-haiku-4-5で再現しています。同じ内容の過去のissue(#23478、#63142、#82482)は、いずれも修正されないまま「not planned」で自動クローズされていました。#96361はその再起票です。

v2.1.288で何が直ったのか

公式のchangelogを遡ると、このissueが指す挙動に対応する修正が2つ見つかります。

issueが報告した2.1.280は、v2.1.288より前のバージョンです。つまり、報告時点の挙動は修正前の仕様だったことになります。memoryのドキュメントも現在は、入れ子のCLAUDE.mdが「サブディレクトリ内の別ファイルをClaudeが読む・書く・編集したときに読み込まれる」と書いています。パス限定ルールも「Read・Write・Editツールが一致するファイルに使われたとき」に読み込まれる、という説明です。

issueのコメントにも裏付けがあります。2026年10月13日のコメントは、macOSのClaude Code 2.1.296で測定した結果として、新規ファイルのWriteを含めて読み込まれると報告しています。

2.1.296での実測 — 読み込むものと読み込まないもの

そのコメントは、InstructionsLoadedフックを基準に、新しいセッションごとに1回のツール呼び出しだけを実行して結果を取っています。表にすると次のとおりです。

重要なのは最後の2行です。Bashの書き込み系は何をしても読み込まれません。Writeの新規ファイルが解決しても、「Bashでファイルを作る」経路は残ります。

ここで、公式のtools-referenceにある単一ファイル読み取りの条件と見比べると、対象コマンドがほぼ重なります。cat・nl・bat・head・tail・sed -n 'X,Yp'・grep系・rgを、パイプもリダイレクトもなしに1ファイルへ使うことが条件です。Bashで読むなら「単純に1ファイルだけ」が安全圏と言えます。

auto modeとの組み合わせで穴が広がる

Bashの書き込みが読み込みの引き金にならないことは、auto modeで効いてきます。issue本文は、auto modeのシステムプロンプトがファイル作業をBash経由に寄せるため、この穴がさらに悪化すると指摘しています。関連するissueは#90450と#95083で、どちらも開いたままです。

この仕組みの詳細は、auto modeでCLAUDE.mdとhooksが無視される問題と回避策で扱っています。今回の件との違いは、Writeの問題が「ツールの種類」の問題で、直った部分があるのに対し、auto modeの問題は「Bash優先の指示」が原因で、ツールを直しても指示が残る点です。

実測コメントでは、Opusのauto modeで5つの編集タスクを3回ずつ試す比較も行われています。bashFirst:trueを確認したセッションでの結果は次のとおりです。

小さな標本で、コメント自身も「修正ではなく回避策」と断っています。それでも何も足さない条件の5/15と比べると差は大きく、指示1つで挙動が変わる材料になります。

自分の環境で読み込みを確かめる

症状の切り分けは、推測ではなくInstructionsLoadedフックで行えます。このフックはCLAUDE.mdや.claude/rules/*.mdがコンテキストに入った瞬間に発火し、load_reasonとtrigger_file_pathを渡してくれます。ブロックや変更はできない、観察専用のフックです。

次の設定例を.claude/settings.local.jsonに置くと、遅延読み込み(入れ子のCLAUDE.mdとパス一致のルール)だけがログに残ります。jqが入っている前提の例です。

{
  "hooks": {
    "InstructionsLoaded": [
      {
        "matcher": "nested_traversal|path_glob_match",
        "hooks": [
          {
            "type": "command",
            "command": "jq -c '{file_path, load_reason, trigger_file_path}' >> /tmp/instructions-loaded.log"
          }
        ]
      }
    ]
  }
}

matcherはload_reasonに対して照合されます。値はsession_start、nested_traversal、path_glob_match、include、compactの5種類です。上の例は起動時に読まれる分を除いています。

あとは目印入りのルールを用意して、読み込みを見るだけです。issueの再現手順を、自分のリポジトリ向けに縮めた形にします。公式のトラブルシュートも「新しい入れ子CLAUDE.mdを試すときは、Claudeに書かせず自分のシェルで作る」ことを勧めています。

mkdir -p .claude/rules r2
printf -- '---\npaths:\n  - "r1/**"\n---\nCANARY-R1-RULE\n' > .claude/rules/r1.md
printf 'CANARY-R2-CLAUDEMD\n' > r2/CLAUDE.md
claude --version

そのうえで新しいセッションを開き、「r1/a.txtとr2/a.txtを新規作成して」と頼みます。/tmp/instructions-loaded.logにpath_glob_matchとnested_traversalの行が出れば、そのバージョンでは新規作成のWriteでも読み込まれています。出ない場合は、使っている経路がBashの書き込みになっていないかを、同じセッションの記録で確かめます。

読み込まれない場面への対処

読み込みの穴が残る環境(バージョンが2.1.288より古い、またはBashで書く運用)では、次の3つが選択肢になります。

2つ目のフックは、additionalContextでClaudeに文面を渡せます。ツール結果の隣にシステムリマインダーとして差し込まれる仕組みです。次は、そのための例です。

#!/bin/bash
# .claude/hooks/reread-new-file.sh(PostToolUseのWrite用)
f=$(jq -r '.tool_input.file_path')
jq -n --arg f "$f" '{
  hookSpecificOutput: {
    hookEventName: "PostToolUse",
    additionalContext: ($f + " を作成しました。Readで開き直し、同じフォルダの規約に合うか確かめてください。")
  }
}'

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          { "type": "command", "command": ".claude/hooks/reread-new-file.sh" }
        ]
      }
    ]
  }
}

v2.1.288以降のWriteなら、このフックは不要な往復になる可能性があります。先に前節のログで、読み込みが起きていないことを確かめてから入れてください。

どこで詰まっているかの切り分け

症状ごとに、見る順番を決めておくと早く片付きます。

経緯と今後の見方

#96361は、起票から約1か月で3件のコメントが付いています。最新は10月26日のコメントで、パッケージごとのCLAUDE.mdを持つモノレポの利用者が、GlobとGrepで規約を探してからWriteで新規ファイルを作る流れで規約が効かないと報告しています。ただしこのコメントのバージョン表記はClaude 3.6556.2というデスクトップアプリのもので、CLIの2.1.xとの対応は書かれていません。v2.1.288以降でも起きているのか、アプリが古いCLIを内包していたのかは、コメントからは判別できません。

読み方としては、Writeの新規ファイルはすでに公式の修正対象になっており、issueが開いているのは主に残りの穴(Bashの書き込みとパイプ類、auto modeのBash優先)のためと考えられます。起票者は「Writeを適用する前にルールを読み込む」ことを求めています。v2.1.288の修正がその順序を満たすのかは、changelogにもmemoryのページにも記載がありません。ルールが書き込みの前に届くのか後に届くのかは、ログの時刻とWriteの実行順を突き合わせて自分の環境で確かめられます。

モノレポでフォルダ単位の規約を運用するなら、置き場所の設計はClaude Codeモノレポ設計が参考になります。他チームのCLAUDE.mdを読み込ませたくない場合はclaudeMdExcludesの設定手順も確認してください。

まとめ

新規ファイルのWriteで読み込まれない件は、v2.1.288で直っています。いま気をつけるのは、Bashでファイルを書く運用、パイプや追加フラグ付きの読み取り、auto modeのBash優先の3つです。詳細な再現手順がissueにあるので、InstructionsLoadedのログで自分の環境を1回確かめれば、フックを足すべきかどうかを決められます。