Claude Media
Claude Codeでcdに許可プロンプトが出る原因と対処法
Claude CodeTips

Claude Codeでcdに許可プロンプトが出る原因と対処法

複合コマンドの確認プロンプトがcdに出る設計上の理由と、2026年8月にWindows Git Bashで誤検知が急増した経緯、確認を減らす選択肢をまとめます。

読了目安 約11分

Claude Codeにcd /path/to/repo && git add file && git commit -m "update"のような複合コマンドを実行させることがあります。このとき確認プロンプトはgit commitではなくcdに対して出ることがあります。GitHub Issueにはこの症状の報告が積み重なっており、原因は一つではありません。移動先が変わるcdとgitの組み合わせは、仕様どおり承認が必要な設計です。ただし2026年8月には、WindowsのGit Bash環境で書き込みを含まない読み取り専用コマンドまで誤って確認対象になる回帰が別に発生しました。

Claude Codeがcdだけを承認対象にする理由

Claude Codeは複合コマンドを&&・||・;・|などの区切り演算子で分解し、サブコマンドごとに読み取り専用かどうかを判定します。複合コマンドの権限判定そのものの仕組みはClaude CodeのBash権限ルールは複合コマンドをどう評価するかで扱っています。その中でもcdは特殊な位置づけです。cd自体は作業ディレクトリ内への移動であれば読み取り専用として扱われ、確認なしで実行されます。

例外になるのがcdとgitの組み合わせです。公式ドキュメントは、cdが今と異なるディレクトリへ移動するときは確認が必要になると説明しています。移動先のディレクトリでgitを実行すると、そのディレクトリのgit hookが実行される可能性があるためです。読み取り専用コマンド同士の組み合わせなら通るはずの複合コマンドが、gitを含んだ瞬間に承認対象へ切り替わります。

cd /path/to/repo && git add CLAUDE.md && git commit -m "update"

このとき確認プロンプトに表示されるのは、判定上ひっかかったcdの部分です。GitHub Issueの報告では、実際に書き込みを行うgit commitではなくcd:*への承認を求めるダイアログが出るという声が複数上がっています。しかも「Yes, and don't ask again」で承認しても、セッション内で繰り返し表示され続けたとされています。承認の主体が読み取り操作に見えるcdに向くため、何を承認しているのか分かりにくいという指摘です。

同じディレクトリへのcdは確認なしで実行される

cdの移動先が今の作業ディレクトリと変わらない場合は、この確認は発生しません。公式ドキュメントは、移動先が現在の作業ディレクトリに解決されるcdはno-opであり、プロンプトを起動しないと明記しています。Claude Codeがすでにいるディレクトリへわざわざcdしてからgitを呼ぶような冗長な複合コマンドを書いた場合は、この確認は出ません。

この挙動はv2.1.113で追加された修正です。cd <現在のディレクトリ> && git …が確認プロンプトを起こさなくなったと変更履歴に記載されています。Claude起動時のディレクトリへcdし直してからgitを呼ぶような冗長なパターンで確認が出ていたのは、この修正より前のバージョンの挙動です。

2026年8月、Windows Git Bashで読み取り専用コマンドまで確認対象になった

cdとgitの組み合わせとは別に、2026年8月にはWindowsのGit Bash環境で、書き込みを一切含まない複合コマンドまで確認プロンプトの対象になる回帰が起きました。v2.1.232では、Git BashがCygwin形式のシンボリックリンクを通した書き込みを見逃す権限バイパスの修正が入りました。この変更と合わせて、cd "絶対パス" && ...型の複合コマンドに対する静的解析も厳格化されました。

GitHub Issueには次のような誤検知が報告されています。

  • 書き込みを含まないsed -nのパイプ処理が「書き込み操作を含む」と判定される
  • 絶対パスへの単純なリダイレクトが「実行時にしか決まらないパス」として保留になる
  • ダブルクオートで囲んだDOSの8.3形式パス(ABCDEF~1のような表記)がbashのチルダ展開と誤認される

これらの誤検知には「don't ask again」の選択肢が用意されず、permissions.allowルールも効かなかったと報告されています。1台の環境では、5日間のBash呼び出し4,519件のうち2,118件(46.9%)がこの形の複合コマンドに該当し、ほぼ1回おきに確認が挟まる状態になったという計測結果も上がっています。

バージョンWindows Git Bashでの挙動
v2.1.231以前Windows Git Bashでの挙動cdを含む複合コマンドは通常の読み取り専用判定に従う
v2.1.232Windows Git Bashでの挙動Cygwinシンボリックリンク対策の追加により、cd "絶対パス" && ...型の複合コマンドが読み取り専用でも確認プロンプトへ落ちる誤検知が急増
v2.1.233Windows Git Bashでの挙動この回帰を修正。Cygwinシンボリックリンク関連の変更とリダイレクト(< file)まわりの変更を一旦ロールバックし、狭い範囲の対応を後日出すと告知

なお公式ドキュメントは別に、10,000字を超えるコマンドは解析しきれないため常に確認が必要になるとも説明しています。長大なヒアドキュメントを複合コマンドに含めると、この一般的な上限にも触れることがあります。

確認プロンプトを減らすための選択肢

cdとgitの組み合わせ自体は設計どおりの挙動なので、ルール側で完全に無効化する公式な手段はありません。GitHub Issueで報告されている選択肢は次のとおりです。

CLAUDE.mdに明示的な指示を書く。「作業ディレクトリへのcdを複合コマンドの先頭に付けない」「Windows Git Bashでは/c/Users/...とC:\Users\...が同じパスとして扱われる」といった指示をCLAUDE.mdに書いたユーザーもいます。ただしその報告では効果は限定的で、セッションのたびに同じ指示を繰り返す必要があったとされています。

PreToolUseフックでcdの連鎖自体をブロックする。フックのライフサイクルでは、PreToolUseは確認プロンプト(PermissionRequest)より先に発火します。終了コード2で終了したフックはツール呼び出しをその場でブロックし、stderrをClaudeに見せます。cdの連鎖を検出して終了コード2で拒否すれば、確認プロンプトの手前でコマンドの書き直しを促せます。

PreToolUseフックでcd連鎖を拒否する例
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/no-cd-chaining.sh\"" }
        ]
      }
    ]
  }
}
#!/bin/bash
# .claude/hooks/no-cd-chaining.sh
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')
 
if echo "$COMMAND" | grep -qP '^\s*cd\s+.+?\s*(&&|;|\|\|)\s*' || \
   echo "$COMMAND" | grep -qP '(&&|;|\|\|)\s*cd\s+'; then
  echo "cdを他のコマンドと連結しないでください。cdと実行コマンドを別のBash呼び出しに分けてください。" >&2
  exit 2
fi
exit 0

ただしGitHub Issueには、このフックを設定してもGit Bash環境ではブロックされる前に内蔵のセキュリティチェック側で確認プロンプトが出たという報告もあります。フックの発火順序どおりに動くとは限らない点は留意が必要です。

git -C <path>でcdそのものを使わない。git -Cはコマンド文字列にcdというトークンを含まないため、cdとgitの組み合わせに対する確認とは別扱いになります。公式ドキュメントは、Bash(git push *)のようなアローリストがgit -C . pushという書き方にはマッチしないと説明しています。同じ理屈はgit commitにも当てはまります。git -Cに切り替える場合、既存のBash許可ルールが素通りしなくなる可能性がある点は確認が要ります。

複合コマンドを分けて実行する。cdと実際のコマンドを1回のBash呼び出しにまとめず、別々に呼び出す方法もあります。こうするとcdは単体の読み取り専用コマンドとして扱われ、後続のコマンドもそれぞれ独立して権限判定されます。GitHub Issueのフック例でも、拒否メッセージの中でこの分割を代替手段として案内しています。

繰り返し発生する確認プロンプトそのものを整理したい場合は、別の選択肢もあります。/fewer-permission-promptsで許可プロンプトを自動整理するに、会話履歴からallowリストへ反映する自動化の手順をまとめています。

よくある質問

一度承認すれば同じcdの確認は次から出ませんか

cdでサブディレクトリへ移動するサブコマンドは、そのパス用のReadルールとして個別に保存されます。ただしGitHub Issueには、cdとgitの組み合わせに対する確認は「Yes, and don't ask again」で承認しても消えないという報告が複数あります。同じセッション内で繰り返し表示されたとされており、保存されたルールとcd+git特有の確認とは別の仕組みで動いている可能性があります。

今使っているバージョンが誤検知の対象か確認する方法はありますか

Windows Git Bashでの誤検知が広く報告されたのはv2.1.232のみで、v2.1.233で修正されています。バージョンはclaude --versionで確認できます。加えて、/permissionsでは現在のセッションで保存されているallow・ask・denyルールを一覧できるので、意図しないルールが増えていないかもあわせて確認できます。操作方法は/permissionsコマンドで権限ルールとauto mode拒否を管理するにまとめています。

この誤検知はWindows以外でも起きますか

GitHub Issueで報告された2026年8月の誤検知は、Git BashのCygwinシンボリックリンク対策が起点になっています。報告はいずれもWindows + Git Bash環境からのもので、同じ2台のマシンでもWSLのbashを経由するセッションでは再現しなかったという報告があります。Git Bash特有の挙動である可能性が高いとされています。Windows環境での別の権限まわりの不具合はautoAllowBashIfSandboxedがシェル展開コマンドで効かなかった不具合とv2.1.139の修正でも扱っています。

まとめ

cdが複合コマンドの確認プロンプトに表示されるのは、多くの場合cdとgitの組み合わせに対する意図的な設計です。移動先のディレクトリでgit hookが実行される可能性を防ぐための確認です。移動先が今のディレクトリと変わらなければ、v2.1.113以降は確認自体が出ません。一方で2026年8月には、それとは別の回帰も起きました。Windows Git Bash環境で無関係な読み取り専用コマンドまで確認対象になる不具合がv2.1.232で発生し、v2.1.233で修正されています。使っているバージョンとOS・シェルの組み合わせによって症状の原因が違うため、claude --versionで対象バージョンかどうかをまず確認する価値があります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →