Claude Code v2.1.214 で allow ルールの dir/** が「効かなくなる」— 棚卸しスクリプトと書き換えの判断基準

settings.json の allow に Edit(src/**) と書いて、毎回の権限プロンプトを黙らせている。Claude Code を自動化に使い込んでいる人ほど、この形のルールが積み上がっているはずだ。v2.1.214 でこのルールの一致範囲が静かに変わった。エラーは出ない。ルールが「効かなくなる」だけだ。筆者は自分の環境の全ルールを棚卸しして、書き換えが必要な設定が何件あるかを確かめた。

【PR】本記事は広告を含みます。末尾の Claude Code 紹介リンクは Anthropic の紹介プログラムのリンクで、登録が有料プランへ進むと筆者に利用クレジットが入ります。

目次

1. v2.1.214 で何が直ったか
2. 何が「効かなくなる」のか
3. 自分の設定を棚卸しする
4. Windows ユーザーは PowerShell 5.1 の修正も自分事
5. 「プロンプトが増えた」と感じたときの切り分け
6. どの設定ファイルに書き直すか
7. 周辺バージョンも権限修正が続いている
8. まとめ

v2.1.214 で何が直ったか

2026年7月18日ごろ配信された v2.1.214 は、権限チェックの修正が集中したリリースだった。公式 changelog から、影響の大きい順に並べる。

changelog の原文はこうだ。

Fixed single-segment `dir/**` allow rules like `Edit(src/**)` auto-approving
writes to nested `dir/` directories anywhere in the tree instead of only `<cwd>/dir`

公式はこれを、gitignore 仕様に反する過剰一致を正したバグ修正と位置づけている。呼び方はどうあれ読者側に起きることは同じで、昨日まで自動承認されていた操作に今日からプロンプトが出る。

何が「効かなくなる」のか

修正後の Edit(src/**) は「カレントディレクトリ直下の src/」だけに一致する。hooks の公式ドキュメントに版付きの注記が入った。

Before v2.1.214, "Edit(src/**)" matched a directory named `src`
at any depth under the working directory.

例えばモノレポで packages/app/src/ を編集させているなら、v2.1.213 までは Edit(src/**) が自動承認していた。v2.1.214 以降は一致しない。ルール自体は設定に残り、構文エラーにもならず、プロンプトが再び出るようになるだけ。任意深度に効かせたければ Edit(**/src/**) と書く。

鍵に例えると分かりやすい。旧挙動の Edit(src/**) は「src という名前の部屋なら、建物のどの階でも開く合鍵」だった。修正後は「玄関脇の src 室だけの鍵」になった。合鍵のつもりで配っていた人は、開かない部屋の前で改めて許可を求められる。逆に、玄関脇だけ開けばよかった人にとっては、今までの合鍵が開けすぎていたことになる。

// v2.1.214 以降の書き分け
{
  "permissions": {
    "allow": [
      "Edit(src/**)",     // カレント直下の src/ だけ
      "Edit(**/src/**)"   // 任意階層の src/（旧挙動相当）
    ]
  }
}

フックの if: 条件も同じ変更を受けた。"Edit(src/**)" を条件にしたフックは、ネストした src/ では発火しなくなっている。

見落としやすいのが deny と ask の扱いだ。changelog は「deny/ask ルールは従来どおり任意深度に一致し続ける」と明記している。締める方向のルールは広く、緩める方向のルールは狭く。安全側に倒した非対称で、この設計は妥当だと筆者は思う。裏を返すと、書き換えるべきは allow と hook の if: 条件だけで、deny は触らなくてよい。

自分の設定を棚卸しする

影響を受けるルールが手元に何件あるか。目視で settings.json を読むより、単一セグメントのパターンを機械で拾うほうが確実だ。筆者はこのスクリプトで全設定ファイルを走査した。

import json, re, glob, os

paths = glob.glob(r"C:\Users\me\projects\*\.claude\settings*.json") + [
    os.path.expanduser("~/.claude/settings.json"),
    os.path.expanduser("~/.claude/settings.local.json")]
pat = re.compile(r"\((?:[A-Za-z]:)?[^*/):]+/\*\*(?::|\))")  # 単一セグメント dir/**

for p in paths:
    if not os.path.exists(p):
        continue
    allows = json.load(open(p, encoding="utf-8")).get("permissions", {}).get("allow", [])
    hits = [a for a in allows if pat.search(a)]
    if hits:
        print(p, hits)

結果、筆者の環境はグローバル27ルール・プロジェクト側も含めて該当0件だった。普段からルールをプロジェクト直下基準（scripts/** をそのプロジェクトの settings.local.json に置く形）で書いていたのが効いた格好で、書き換え作業は発生しなかった。

このスクリプトが走査するのは permissions の allow だけだ。フックの if: 条件は settings 内の hooks ブロックに書かれているので、grep -n "if.*(/\*\*" settings.json のような検索で別途拾う必要がある。

0件なら安心、1件でもあれば判断が要る。そのルールが「カレント直下だけで十分だったのか」「任意深度に効いてほしかったのか」は本人にしか分からない。深く効かせたかったものだけ **/dir/** に書き換える。全部を機械的に **/ 付きへ変換するのは、旧挙動の過剰一致をわざわざ復元する行為なのでやめたほうがいい。

Windows ユーザーは PowerShell 5.1 の修正も自分事

表の2行目、PowerShell 5.1 の権限チェックバイパス修正は Windows ユーザー専用の話だ。5.1 は Windows に標準搭載されている「Windows PowerShell」のことで、後から入れる PowerShell 7 系と併存する。自分では 7 系しか使っていないつもりでも、ツールチェーンの奥で 5.1 が呼ばれる構成は珍しくない。標準搭載側のセッションだけ権限チェックが素通りしていたというのがこの修正で、筆者のようにメイン環境が Windows 11 の人間には、単一セグメント問題より先にこちらで青くなる可能性があった。

同じリリースには地味な fail-closed 化も複数入っている。ファイルディスクリプタのリダイレクトを権限アナライザが bash と違う解釈をしていた形は「解釈できないなら止める」方向へ、help や man 経由で危険なオプションやコマンド置換が動く形は自動承認の対象外へ。傾向として、判定に迷うものは全部プロンプトに倒すという設計方針がはっきりしてきた。自動化の快適さは少し削られるが、筆者はこの方向を支持する。黙って通る誤判定は、プロンプトが1回増えることの何倍も高くつく。

「プロンプトが増えた」と感じたときの切り分け

この修正の厄介さは、症状が「なんとなくプロンプトが増えた」としか感じられないところにある。筆者ならこの順で切り分ける。

最初に claude --version（またはセッション内の /status）でバージョンを確かめる。v2.1.214 より前なら今回の話は関係がない。次に、プロンプトが出た操作のパス（例: packages/app/src/index.ts への Edit）を見て、そのパスを許可しているはずのルールを settings から探す。そこに単一セグメントの dir/** がいたら、ほぼ確定だ。最後に、そのルールを深く効かせたかったかを自分に問い、答えが Yes のときだけ **/dir/** へ書き換える。

1行だけ補足する。

プロンプトの増加には v2.1.212 の plan モード修正（touch や rm が黙って通っていた問題）や v2.1.214 の長大コマンド・zsh 添字まわりの修正も同時に効いている可能性がある。「増えた」の犯人は1つとは限らないので、パス系のルールで説明がつかなければ changelog の他の項目を疑う。

どの設定ファイルに書き直すか

書き換えのついでに置き場所も見直す価値がある。筆者の使い分けはこうだ。共有してよいプロジェクト固有ルールは .claude/settings.json（リポジトリにコミットされる）、自分の環境だけの許可は .claude/settings.local.json、マシン全体の方針は ~/.claude/settings.json。今回の棚卸しで0件で済んだのも、ルールを各プロジェクトの settings.local.json に「そのプロジェクトのカレント基準」で書く癖がついていたからで、グローバル側に **/ 付きの広いルールを溜め込む運用だったら結果は違ったと思う。

関連して v2.1.211 では「always allow」で保存した承認がリポジトリルートに記録されるようになり、git worktree をまたいでも承認が持続する。worktree で並行作業をする人は、承認の効き先が「そのworktree」から「リポジトリ」へ広がった点も頭に入れておくとプロンプトの出方に説明がつく。

棚卸しを機に、allow ルールの設計を原則から立て直すならこう考える。許可は「そのプロジェクトで実際に繰り返される操作」だけに絞り、グローバルには読み取り系と、どのプロジェクトでも同じ意味を持つコマンドだけを置く。パスの許可は原則カレント基準の狭い形で書き、**/ を付けるのは「どの深さでも同じ扱いでよい」と言い切れるものに限る。半年に一度ルールを見直して、使っていない許可を消す。権限まわりの修正がこれだけ続いている以上、ルールは書きっぱなしにできない運用対象だと考えたほうがいい。

周辺バージョンも権限修正が続いている

v2.1.214 だけが特別ではない。この2週間の changelog は権限まわりの修正が続いていて、自動化ユーザーには流れごと把握する価値がある。

筆者の手元は既に v2.1.217 で、この記事の仕様確認はすべて修正後のバージョンと公式文書に基づく。v2.1.213 以前の実機を並べた A/B 比較はしていない（旧バージョンの挙動は changelog と公式ドキュメントの記述に依拠している）。

まとめ

やることは2つ。grep なり上のスクリプトなりで allow ルールとフック条件から単一セグメント dir/** を拾い出す。拾えたものについて、任意深度に効いてほしかったものだけを **/dir/** へ書き換える。deny/ask はそのままでいい。

プロンプトが増えたと感じたら、それは v2.1.214 が「昨日まで素通りしていた操作」を見せてくれているということでもある。筆者はプラン変更の検証のときと同じく、まず一次ソースの changelog を読む習慣に助けられた。挙動の変化を感じたら changelog を直接開く。結局それがいちばん早い。