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

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が別のコマンドと組み合わさったときです。

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はno-opであり、プロンプトを起動しないと明記しています。この挙動はv2.1.113で入った修正で、変更履歴にはcd <現在のディレクトリ> && git …が確認を起こさなくなったと載っています。

cdとリダイレクトの組み合わせ

gitを使わないコマンドでも、cdのあとにリダイレクトが続くと確認が出ることがあります。公式ドキュメントは、cdを実行した後にリダイレクト先がどのディレクトリ基準で解決されるかをClaude Codeが判定できないとき、確認が必要になると説明しています。

例外は書き込み先が/dev/nullだけの場合です。/dev/nullは作業ディレクトリに依存しないため、cd app; grep -r pattern . 2>/dev/nullは確認なしで通ります。変更履歴では、この/dev/nullの扱いがv2.1.207で修正されています。

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

cdとgitの組み合わせとは別に、2026年8月にはWindowsのGit Bash環境で、書き込みを一切含まない複合コマンドまで確認プロンプトの対象になる回帰が起きました。経緯は次のタイムラインのとおりです。

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回おきに確認が挟まる状態になったという計測結果も上がっています。

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

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

cdとgitの組み合わせ自体は設計どおりの挙動です。設定だけで外す手段は、公式ドキュメントに載っていません。確認を減らす別の入口として、PreToolUseフックの出力で呼び出しを許可し、確認を省く方法があります。ただしdenyルールとaskルールはフックの返り値にかかわらず評価され、一致すればブロックや確認が残ります。permissions.denyにRead()のルールを1つでも置いていると、これとは別の理由でcdを含む複合コマンドの確認が増えることもあります。詳しくはRead denyルールがあるとcd複合コマンドで承認が求められるで扱っています。同じ確認プロンプトでも、critical pathを対象にしたrmはより厳格で、環境変数で局面別に無効化する方法はあっても既定では許可ルールで承認できません。

セッションごと移動する。複数のディレクトリを行き来してcdとgitを連結するなら、/cd <path>でセッションの作業ディレクトリ自体を移す方法があります。会話は保たれ、移動先のCLAUDE.mdやプロジェクト設定(権限ルールとhookを含む)がすぐに効きます。未信頼のディレクトリでは信頼確認が出る点は、cd連結の承認とは別の扱いです。/cdの移動先はCd権限ルールで制限や無効化もできます。

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

git -C <path>でcdそのものを使わない手もあります。git -Cならコマンド文字列にcdが現れません。ただし公式ドキュメントは、Bash(git push *)のアローリストがgit -C . pushという書き方にはマッチしないと説明しています。git -Cに切り替えると、既存のBash許可ルールが素通りしなくなる可能性があります。

CLAUDE.mdに明示的な指示を書く方法です。「作業ディレクトリへのcdを複合コマンドの先頭に付けない」と書いたユーザーもいます。Git Bashでは/c/Users/...とC:\Users\...が同じパスだという説明を足した例も報告されています。ただしその報告では効果は限定的で、セッションのたびに同じ指示を繰り返す必要があったとされています。公式ドキュメントも、CLAUDE.mdの指示はClaudeが試す内容を左右するだけで、Claude Codeが許可する内容は変えないと説明しています。

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

{
  "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環境ではブロックされる前に内蔵のセキュリティチェック側で確認プロンプトが出たという報告もあります。フックの発火順序どおりに動くとは限りません。

保存された承認ルールは/permissionsで一覧できます。意図しないルールが増えていないかの確認は、/permissionsコマンドで権限ルールとauto mode拒否を管理するの手順で行えます。繰り返す確認そのものを整理したいなら、/fewer-permission-promptsで許可プロンプトを自動整理するに、会話履歴からallowリストへ反映する自動化の手順をまとめています。

よくある質問

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

複合コマンドを「Yes, and don't ask again」で承認すると、承認が必要なサブコマンドごとに別々のルールが保存されます。作業ディレクトリの外へcdするサブコマンドは、そのパスのReadルールとして保存されます。ただしGitHub Issueには、cdとgitの組み合わせに対する確認は承認しても消えないという報告が複数あります。保存されたルールと、移動先のhookを警戒するcd+gitの確認は、別の仕組みで動いている可能性があります。

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

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

まとめ

確認が出たら、コマンドにgitが含まれるか、cdのあとにリダイレクトがあるか、移動先が作業ディレクトリの外か、の順に見ます。最初の2つならcdと本体のコマンドを別々に呼ぶかgit -Cに替え、外への移動なら/cdでセッションごと移すと避けられます。gitを含まない読み取り専用コマンドがWindowsのGit Bashで止まるなら、claude --versionでバージョンがv2.1.232かどうかも確かめます(v2.1.233で直っています)。