結論：まずversionを確認し、全許可ではなく回帰・設定・経路を分ける
Claude Code 2.1.270の公式changelogには、長時間sessionの後にBash内のread-only Git commandが予期せずpermissionを求める回帰の修正が記載されています。
2.1.269で発生しているなら、最初にversionを記録して2.1.270以降で再現するかを確認します。それでも要求が出る場合は、読み取り専用に見える名前だけで判断せず、実際のcommand、repository、wrapper、設定scope、hookを順番に調べます。確認中にpermissionを全面的に許可するのは避けてください。
根拠はClaude Code公式changelogの2.1.270と、権限の考え方を説明する公式 permissions guideです。設定の優先順位と環境別の指定は公式 settingsも参照します。修正対象の回帰と、自社の権限設計を混同しないことが重要です。
同じ「許可要求」でも原因は違う
| 観察した状態 | 主な仮説 | 先に残す記録 |
|---|---|---|
| 2.1.269で長時間後に発生 | 公式changelogの回帰に該当 | version、経過時間、command |
| 更新後も特定repoだけ発生 | repository、wrapper、hook、設定の差 | cwd、実行ファイル、設定source |
| 書き込みを含むcommandで発生 | 操作がread-onlyではない | command全体、引数、変更有無 |
| managed環境だけ発生 | 組織ポリシーやpermission mode | 適用scope、承認者、policy |
git statusやgit diffのような操作でも、実行場所が意図したrepositoryか、shell wrapperが別処理を追加していないかを見ます。Bashの文字列に秘密情報やtokenを貼り付けてログ共有しないでください。エラー報告には必要な識別子だけを残し、入力・認証情報はマスクします。
既存の無人実行のprompt待ちを止める記事はheadless jobで拒否結果を扱う方法、managed settings承認の記事は組織設定の変更を扱います。今回の検索意図は、Gitの読み取り操作が長時間session中に要求される現象の切り分けです。原因がworkspaceの信頼性ならworkspace trustの確認へ分岐します。
切り分け手順：8ステップで安全に再現する
claude --versionの結果、OS、利用面、session開始時刻を記録します。エラー画面だけでなく、再現した時刻を残します。- 2.1.269なら、変更内容とrollback方法を確認したうえで2.1.270以降へ更新し、更新前後のversionを台帳へ保存します。
- 同じrepositoryのコピーまたは安全なfixtureで、短時間の新規sessionを起動します。本番の未commit変更を検証に使いません。
- 対象をread-onlyのGit確認、ファイルを変える操作、外部送信を伴う操作の三群へ分け、一つずつ実行します。
- 許可要求が出たcommandの全体、cwd、引数、実行ファイル、時刻を確認します。shell wrapperやaliasも含め、実際の経路を見ます。
- user、project、local、managedの設定をsource別に比較し、同じruleが異なるscopeから重複していないかを確認します。
- 長時間経過、compact、resume、model切替など一つの条件だけを変えて、再現する条件としない条件を表にします。
- 回帰なら更新・再検証、設定差なら最小ruleへ修正、仕様上の要求なら個別承認または拒否を選び、判断と期限を記録します。
更新後に要求が消えたとしても、ただちに権限ruleを広げる必要はありません。再現しなかった条件、確認できていない条件を「未確認」として残します。逆に、別のcommandがファイルを書き換えていた場合は、Gitという名前に引っ張られず、書き込み操作として確認します。
企業運用で決めるべき承認境界
開発者が毎回承認する運用は、短期的には進みますが、長いsessionで確認が形骸化しやすくなります。read-onlyの確認、ローカルfixtureの変更、共有branchへの書き込み、外部サービスへの送信を別のリスクとして扱い、ruleの対象を分けます。ruleの追加者、レビュー者、適用scope、期限、解除方法を台帳に持たせます。
組織として一律のruleを配る場合は、managed settingsが個人の判断を上書きする可能性を確認します。更新時に設定形式が変わることもあるため、version更新を単なるインストール作業にせず、代表repositoryで権限の回帰テストを実施します。テストには成功だけでなく、危険操作が止まることも含めます。
公式changelogの修正は、特定versionの不具合に対する手掛かりです。自社のwrapper、Git hook、MCP、proxy、OS権限まで自動で直すものではありません。原因が外部送信やMCPならMCPのセキュリティ確認へ、観測の差ならtelemetryの監査へ切り分けます。
チェックリスト：更新後に残す証跡
□versionと更新日時を保存したか □2.1.269の回帰と推測できる条件を記録したか □本番ではなくfixtureで試したか □command全体とcwdを確認したか □wrapper・alias・hookを見たか □read-onlyと書き込みを分けたか □設定sourceとscopeを比較したか □全許可ruleを追加していないか □再現条件と未確認条件を分けたか □承認者・期限・rollbackを決めたか □更新後も危険操作が止まるか確認したか。
よくある質問
Git statusだけなら常に安全ですか？
名前だけでは断定しません。対象repository、wrapper、hook、実行ユーザー、cwdを確認し、実際に書き込みや外部送信が発生しないかを分けて検証します。
2.1.270へ更新すれば全て直りますか？
2.1.269の回帰に該当する問題の修正は期待できますが、設定scope、wrapper、repository権限、別の書き込み操作まで解決するとは限りません。
確認のためにpermissionを全許可してよいですか？
避けます。短い再現と最小範囲の承認を使い、必要なruleだけを期限付きで追加します。秘密情報や認証情報はログへ貼りません。
公式情報と無料診断
versionごとの修正は公式changelog、承認の考え方はpermissions guide、設定scopeはsettings公式文書を公開直前に確認しました。Miraigentの無料診断では、更新テスト、権限境界、承認台帳を業務に合わせて整理できます。