長時間セッションでgit statusが急に許可を求めてくる——Claude Code 2.1.269の権限プロンプト回帰を追った
Claude Code 2.1.269で、読み取り専用のgitコマンドがセッション経過後に突然許可を求める回帰バグが発生。公式リリースノートで確認した原因の見立てと、2.1.270での修正内容、影響を受けているか確認する手順を整理した。
エンジニアのゆとです。
git statusとかgit diffとか、読むだけで何も壊さないコマンドのはずなのに、セッションを開始してしばらく経つと急に「実行しますか?」と聞かれるようになる——2026年9月11日にリリースされたClaude Code 2.1.269で、こういう報告が増えた。
allowルールにgit statusもgit diffもgit logも全部入れてあるのに、なぜか数十ターン進んだあたりから聞かれ始める。設定ミスかと思ってsettings.jsonを何度も見直した人もいたはずだ。結論から言うと、これは設定ミスではなくClaude Code側の回帰バグで、翌日リリースされた2.1.270で直っている。
まず結論——2.1.269だけの一過性バグ、2.1.270で修正済み
対象になっていたのは以下の条件。
- Claude Codeバージョン: 2.1.269（2026年9月11日リリース）
- 症状:
git status/git diff/git logのような読み取り専用のgitコマンドが、Bashツール経由で実行されたとき、セッションがある程度の長さ動いた後に突然「実行を許可しますか?」と聞かれるようになる - 発生条件: セッション開始直後は起きない。ターン数がある程度進んだ、つまり「しばらく動かした後」に発生する
Anthropicはこれを2.1.269のリリースノートには記載せず、翌日の2.1.270で以下のようにひっそり修正した。
Fixed read-only git commands in Bash unexpectedly asking for permission
after a session had been running for a while (regression in 2.1.269)「2.1.269での回帰」と明記されているので、原因が2.1.269のどこかにあることは公式に認めている。今Claude Codeを2.1.270以降にアップデートしていれば、この症状はもう起きない。まだ2.1.269のままなら、まずアップデートで解決する話だ。
何が起きていたか——「慣れてきた頃」に裏切られる
このバグの厄介なところは、再現条件が「セッションの長さ」という、ユーザー側からは制御しづらい変数に依存している点にある。
典型的な流れはこうだ。
- 新しいセッションを開始する。
git statusやgit diffを何度か使うが、最初のうちは問題なく通る - 実装を進めながらコミットを重ね、セッションが長くなっていく
- ある時点から、それまで無反応で通っていたはずの
git statusが急に確認プロンプトを出すようになる settings.jsonのallowルールを見直しても、Bash(git status:*)のような記述はちゃんと入っている。設定は変わっていないのに挙動だけが変わる
普段autoモードやallowlistを整えて「読み取り系は何も聞かれない」状態に慣れている人ほど、この変化に気づいたときの違和感が大きい。しかもセッション序盤では再現しないので、「さっきまで平気だったのに」という形で不意打ちを食らう。GitHub Issueや海外コミュニティでも、長時間の自律実行(auto/bypassPermissionsに近い運用)をしているユーザーからの報告が目立っていた。
なぜ起きたのか——2.1.269で強化された権限チェックの副作用という見立て
Anthropicは「何が原因だったか」の技術的な内訳までは公開していない。ただし2.1.269自体のリリースノートを見ると、権限チェックまわりに複数の変更が同時に入っていることがわかる。
Fixed Bash permission checks missing the file that `fmt`, `column` and
similar commands read when it follows an option the checker doesn't recognize
Fixed Bash permission checks skipping files a wildcard expands to when the
wildcard sits in a command's pattern or option value (for example `grep -v dir/* file`)
Fixed Bash permission checks so that shell variable declaration flags cannot
misrepresent the command being run
Fixed Bash commands with two directory changes, a subshell, or a `cd`+`git`
chain skipping the prompt under `permissions.blockReadsOutsideWorkingDirectories`
in bypass and auto mode見ての通り、2.1.269は「これまで見逃されていた抜け道を塞ぐ」方向の権限チェック強化を4件まとめて入れている。特に最後の「cd+gitチェーンがプロンプトをスキップしていたのを修正」という項目は、gitコマンドの権限判定ロジックそのものに手を入れたことを示している。
セッションが長くなるとClaude側が生成するBashコマンドの形も複雑になりやすい(前のターンでcdした場所を引き継ぐ、複数コマンドを&&で連結する、といった具合)。この強化された判定ロジックが、単純なgit status単体ではなく、何らかの複合的な実行パターンに乗ったときだけ誤って「要確認」と判定していた、というのが一番筋の通る見立てだ。2.1.270のリリースノートが「read-only git commands … after a session had been running for a while」と、症状の条件(読み取り専用・長時間経過後)だけをピンポイントに言い当てていることからも、原因箇所を狭く特定できていたことがうかがえる。
いずれにせよ、これは「セキュリティを塞ぐための修正が、塞ぐべきでないところまで巻き込んだ」という点で、直前に自分が別記事で扱った2.1.259のcd複合コマンド誤検知と構造がよく似ている。
権限チェックの強化と誤検知の発生は、Claude Codeのアップデートでは繰り返し起きているパターンだと捉えておいたほうがいい。「新しいバージョンが出た直後は、権限まわりの挙動が変わっていないか一度様子を見る」くらいの慎重さがちょうどいい。
自分のバージョンを確認して、必要ならアップデートする
対処はシンプルで、2.1.270以降にアップデートすれば直る。まず今のバージョンを確認する。
claude --version2.1.269と出た場合はこの回帰の影響を受けている可能性がある。2.1.270以降ならすでに直っている。アップデート自体は通常のアップデートコマンドで完了する。
claude updatenpm経由でインストールしている場合は以下でも上げられる。
npm install -g @anthropic-ai/claude-code@latestアップデート後にもう一度claude --versionで反映を確認しておく。社内やチームで固定バージョンを配布している場合は、2.1.269を検証用に触ったユーザーから同じ報告が上がっていないか一声かけておくと親切だ。
バージョンを意図的に固定している場合の注意
チーム運用でバージョンを意図的にピン留めしている現場もあると思う。その場合、2.1.269を検証済みバージョンとして選んでしまうと、このバグをそのまま配布することになる。ピン留めの運用をしているなら、少なくとも2.1.270以降を対象にするのが無難だ。
バージョン固定の具体的なやり方は以前まとめている。
逆に「毎回最新版に自動アップデートする」運用をしている場合は、今回のように1日で修正されるパターンならそこまで気にしなくていい。ただし今回はたまたま翌日に直っただけで、常に即日修正される保証はない。権限プロンプトの挙動が急に変わったと感じたら、まずclaude --versionで今のバージョンを確認し、直近のリリースノートにpermissionやgit関連の変更が入っていないか見る、という手順を習慣にしておくと切り分けが早い。
似たバグと混同しないための整理
Claude Codeの権限プロンプトまわりでは、似たタイミングで複数の不具合が話題になることがある。今回のバグと、自分が以前扱った2.1.259のcd複合コマンド誤検知は、症状が近いので混同しやすい。整理しておく。
| 2.1.269の回帰(本記事) | 2.1.259のcd複合コマンド誤検知 | |
|---|---|---|
| 対象コマンド | 読み取り専用のgitコマンド(git status/git diff/git log) | cdを含む複合コマンド全般 |
| 発生条件 | セッションがある程度長く動いた後 | Read()拒否ルール設定時、cdの後に;や複数&&が続くコマンド |
| 修正状況 | 2.1.270で修正済み | 記事執筆時点で複数バージョン未修正が続いていた |
| 影響モード | 通常の権限チェック全般 | auto/bypassPermissionsを含む全モード |
どちらも「権限チェックの強化がやりすぎて安全な操作まで止める」という方向性は共通しているが、発生条件とバージョンが違う。今使っているバージョンとエラーの出方を照らし合わせて、どちらの話をしているのか区別したほうがいい。
運用の教訓——allowlistが正しくても挙動は変わりうる
今回の件で自分が改めて意識したのは、「settings.jsonのallowlistが正しく書けていれば権限プロンプトの挙動は安定している」という前提自体が、Claude Codeのマイナーアップデートを挟むと崩れうるということだ。allowlist側の設定は一切変えていなくても、CLIのバージョンが上がるだけで判定ロジックが変わり、それまで無反応だったコマンドが急に確認を求めてくる。
自分のyuto-lab.com運用では、長時間の自律実行タスクをauto modeで回すことが多い。今回のバグはその手の運用ほど影響が出やすいパターンだったので、アップデート直後の1セッション目は複合的なコマンドを含むタスクで様子を見て、想定外のプロンプトが出ないか確認してから本番の長時間タスクに戻す、という手順を自分のルーティンに足すことにした。
まとめ
Claude Code 2.1.269では、読み取り専用のgitコマンド(git status/git diff/git log)がセッション経過後に予期せず許可プロンプトを出す回帰バグが発生していた。原因の詳細は非公開だが、同バージョンで同時に入った複数の権限チェック強化のどれかが引き金になったと見て間違いなさそうだ。翌日リリースの2.1.270で修正済みなので、claude --versionで2.1.269のままになっていないか確認し、該当する場合はアップデートすれば解決する。バージョンを固定運用している場合は、2.1.269を採用バージョンに選ばないよう注意したい。
権限チェックの強化と誤検知はClaude Codeのアップデートでたびたび起きているので、「新しいバージョンが出た直後は権限まわりの挙動を一度疑ってみる」くらいの構えでいるのがちょうどいい。
