コミットを頼むたびに、同じ承認の画面が出ておりました。許可ルールには Bash(git add *) も Bash(git commit *) も入れてあるのに、です。個人開発のアプリを直していた夜、十回ほど「Yes」を押したところで、手が止まりました。
画面をよく見ると、聞かれているのは git add でも git commit でもありませんでした。cd です。
最初にお伝えしたいのは、この挙動は許可ルールの書き間違いではないことが多いという点です。公式の権限ドキュメントを読み直して、ようやく線が引けました。その道筋を書き残します。振り返ると、設定を疑う前に画面の文言を読めていなかったのだと気づきました。
症状の見分け方
次の3つがそろっているなら、同じ原因の可能性が高いと思います。
- Claude が
cd /path/to/repo && git add ... && git commit ...のように、1行に繋げたコマンドを出しています。 - 承認画面が
cdに関する内容、またはコマンド全体を求めてきます。 - 「Yes, and don't ask again」を選んでも、次の実行でまた同じ画面が出ます。
GitHub にも同じ報告があります（anthropics/claude-code の Issue 28240）。バージョン 2.1.52 で、Windows、cd /some/path && git add file && git commit で cd:* の承認が出続け、セッション内で許可にできない——という内容です。以前は git add と git commit が聞かれていた、と書かれています。
公式ドキュメントが言っていること（2026 年 10 月 13 日に確認）
権限のページには、複合コマンドの扱いがまとまっています。要点は4つでした。
| 項目 | 書かれていること |
|---|---|
| 区切りの認識 | &&、||、;、|、|&、&、改行で分割され、各サブコマンドが個別にルールと照合される |
| 「今後は確認しない」 | 複合コマンド全体ではなく、承認が必要だったサブコマンドごとにルールが保存される（1つの複合コマンドから最大5件） |
cd 単体 | 作業ディレクトリか追加ディレクトリの内側への cd は読み取り専用扱い。cd packages/api && ls は、各部分が単独で通るなら承認なしで動く |
cd と git | 別のディレクトリへ cd する場合は、各部分が読み取り専用でも承認が出る。理由は「新しいディレクトリの hooks を git が実行しうるため」。cd の行き先が現在の作業ディレクトリ自身なら何もしない扱いで、プロンプトは出ない |
つまり、cd /別の場所 && git add ... は、git 側の許可ルールがどれだけ揃っていても、組み合わせそのものが承認の対象になるのです。Issue では不具合として報告された挙動が、いまのドキュメントでは仕様として説明されています。ただ、報告の時点と現在で挙動が同じかどうかまでは、私の手元では確かめておりません。
もう一点、cd にリダイレクトが付く場合（cd app; grep -r pattern . 2>/dev/null のようなもの）も、行き先が決まらないと承認が出ます。/dev/null だけは作業ディレクトリに依存しないため、例外です。
切り分けの順番
承認が出たら、次の順で見ていきます。
- どのコマンドを聞かれているかを読みます。
gitではなくcdなら、上の「cdとgit」に当たる可能性が高いです。 cdの行き先が作業ディレクトリ自身かを確かめます。違うなら、そこが原因です。- 違わないのに出るなら、
&&の後ろが空でないか、コマンドが 10,000 文字を超えていないか、未クォートの glob を含んでいないかを見ます。いずれも「解析できないので承認を求める」側に倒れます。 - それでも説明がつかないときは、
/permissionsで、保存されているルールの綴りを疑います。
手数を減らす4つの直し方
1. Claude Code を、作業したいリポジトリの中で起動する
いちばん確実だと感じたのは、これです。起動したディレクトリが作業ディレクトリですので、cd の行き先がそのディレクトリなら承認の対象になりません。複数のリポジトリを跨いで作業しているなら、リポジトリごとにセッションを分けます。
2. 別ディレクトリを使うなら、追加ディレクトリに入れる
作業ディレクトリの外のリポジトリを触る必要があるときは、--add-dir か設定の additionalDirectories で、先に追加しておきます。公式は、追加ディレクトリへの cd も読み取り専用として扱うと書いています。ただし、上の表のとおり、cd と git の組み合わせで別ディレクトリへ移る場合は、追加ディレクトリでもプロンプトが出る可能性があります。ここは、手元で一度確かめてから使うのが安全です。
3. 繋げずに、コマンドを分けてもらう
cd を使わず、リポジトリ内で git add と git commit を別々に実行してもらいます。ただし、git -C <path> add ... のような別形式は、公式の表では「Bash(git push *) の deny が git -C . push には効かない」と説明されており、ルールが同じ形に一致するとは限りません。形式を替えるなら、許可ルールも同じ形で入れる必要があります。
4. CLAUDE.md に書くが、期待しすぎない
「複合コマンドで cd を使わない」と CLAUDE.md に書く方法は、Issue のコメントでも試されています。ある方は、大文字で強調して記憶ファイルにも書いて、減ったのは半分程度だったと報告しています。毎回守られるわけではない、と考えておくほうが、あとで困りません。
PreToolUse の hook でコマンド全体を見て許可を返す案もコメントにありました。ただし、同じコメントには注意書きがあります。cd x && <読み取りだけ> を自動で許可する hook を書くなら、cd x && rm -rf ... のような破壊的な連結を対になる形で拒否しておかないと、速い通り道が危険な通り道になる、というものです。私はこの指摘に、いちばん頷きました。
避けたい直し方
Bash(cd *) を allow に入れれば静かになるのでは、と最初は考えました。ですが、承認が cd と git の組み合わせに対して出ているなら、cd を許可しても組み合わせの扱いは変わらない、と読めます。しかも、広い allow は、あとで自分が何を許したのか分からなくなる原因になります。
承認の回数を減らすために、許可の範囲を広げません。 手数は作業の置き場所で減らし、許可は狭いまま残すようにしています。
まずは、次に承認画面が出たとき、聞かれているコマンドが git なのか cd なのかを一文字ずつ読んでみてください。それだけで、設定を触るべきか、起動する場所を変えるべきかが見えてきます。