Claude Codeの/cdコマンドを権限ルールCdで制限する

/cdの移動先は、権限ルールCdで制限できます。Cdルールは/cdコマンドが移動できるディレクトリを決めるルールで、設定ファイルのpermissionsにBashやReadと同じ形で書きます。

ここで押さえる点は3つあります。

• 裸のCdをdenyに入れると、/cdそのものが使えなくなる
• Cd(パターン)のdenyは、一致する移動先だけを止める
• Cdのallowを1つでも足すと、許可リスト方式に切り替わる

cdを含むBashの複合コマンドで承認が求められる問題は別の話で、cd許可プロンプトの原因と対処で扱っています。ここで扱うのは、人が打つ/cdの側です。

なぜ/cdに専用の権限ルールがあるのか

/cd <path>は、会話を保ったままセッションの作業ディレクトリを切り替えるコマンドです。/add-dirが作業ディレクトリを「足す」のに対し、/cdは主たる作業ディレクトリを「移す」点が違います。

移動の効果は、ファイルを読める範囲が変わるだけでは済みません。移動した瞬間に、移動先のプロジェクト設定が適用されます。

もう一方の側では、前のディレクトリのプロジェクト／ローカルスコープのMCPサーバーが切断されます。--add-dirや/add-dirで足したディレクトリは維持され、additionalDirectoriesは移動先の設定から取り直されます。

未信頼のディレクトリへ移るときは、信頼ダイアログが出ます。ダイアログには、そのディレクトリの設定が有効にするallowルール、追加ディレクトリ、hooks、ヘルパーコマンドが並びます。断ればセッションはその場に残ります。ここで挙げた即時適用はv2.1.246以降の挙動で、それ以前は--resumeするまで移動先の設定やhooksは効きませんでした。

移動後に起動するhooksが受け取る${CLAUDE_PROJECT_DIR}は、移動先ではなく、セッションを始めたプロジェクトのルートのままです。移動したセッションは、新しいディレクトリで--resumeを実行すると見つかります。

つまり/cdは、別プロジェクトのhooksや.mcp.jsonを現在のセッションに持ち込める入口です。共有端末や、触らせたくないリポジトリが並ぶ環境では、移動先を絞る価値があります。

/add-dirは設定を読まず、/cdは読む

/add-dirや--add-dirで足したディレクトリは、ファイルを読み書きできる範囲が広がるだけです。移動先の.claude/の設定は、ほとんど読み込まれません。例外は、skills、コマンドファイル、サブエージェントと、設定のenabledPlugins・extraKnownMarketplacesの2キーだけです。CLAUDE.mdは環境変数CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1を設定したときに限って読み込まれます。設定ファイルのadditionalDirectoriesに書いたディレクトリは、ファイルアクセスを広げるだけで、これらの例外も働きません。

対して/cdは、移動先の権限ルール、hooks、.mcp.json、envまでまとめて適用します。足すだけの操作と、主たる作業ディレクトリを移す操作で、持ち込まれる設定の量がまったく違います。Cdルールがあるのは、/add-dirにはない影響が/cdにあるからです。

移動先が未信頼のときは、信頼ダイアログが関門になります。プロジェクトの.claude/settings.jsonにあるpermissions.allowとadditionalDirectoriesは、権限を広げる設定なので、ダイアログで承認するまで適用されません。denyとaskは制限するだけの設定なので、承認を待たずに効きます。つまりCdのdenyは、信頼ダイアログとは別に、移動そのものを手前で止める層になります。

Cdルールの3つの書き方

Cdは、BashやReadと同じくpermissionsのallow・denyに入れます。モデルが呼び出すツールではないので、ClaudeがCdを実行することはありません。ルールが効くのは、人が/cdを打ったときだけです。

裸のdenyで/cdを無効にする

{
  "permissions": {
    "deny": ["Cd"]
  }
}

引数なしのCdをdenyに置くと、/cdは使えなくなります。セッションの作業ディレクトリを起動時のまま固定したいときの書き方です。

パターン付きのdenyで移動先を塞ぐ

{
  "permissions": {
    "deny": ["Cd(~/work/secret-*)", "Cd(//etc/**)"]
  }
}

Cd(パターン)のdenyは、一致する移動先だけを止めます。denyは移動先の綴りを複数のかたちで調べます。シンボリックリンクをたどる各段階も対象なので、あるパスを塞ぐルールは、そこへ解決されるリンク経由の移動先も塞ぎます。

allowを足すと許可リスト方式になる

{
  "permissions": {
    "allow": ["Cd(~/code/**)"]
  }
}

Cdのallowルールが1つでもあると、/cdは許可リスト方式に切り替わります。解決後の移動先がallowのどれかに一致しなければ、/cdは拒否されます。

Cdルールが1つもない状態は、既定の挙動のままです。見慣れないディレクトリに対しては、信頼するかどうかを尋ねます。ほかの権限ルールと同じく、denyはどのスコープのallowよりも先に評価されます。許可リストの中に塞ぎたい例外があるときは、denyを併用します。

パターンの書き方 — アンカーと*・**

Cdのパターンは、ReadやEditと同じ//・~/・/のアンカーを使います。ただし照合はgitignore風ではなく、ディレクトリのパス全体に対して行われます。

/pathの起点は、ルールを書いた設定ファイルで変わります。プロジェクト設定とローカル設定では主たる作業ディレクトリ、ユーザー設定では~/.claudeです。ユーザー設定に/始まりで書いても、ホームや絶対パスにはなりません。ユーザー設定では//か~/を使います。起点の詳しい対応はReadルールのパス起点の記事にあります。

ワイルドカードは2種類です。

• *は、ちょうど1つのパスセグメントに一致する
• **は、複数のセグメントをまたいで一致する
• 末尾の/**は、名指しした根のディレクトリ自身にも一致する

Cd(~/code/*)は~/code自身を含まず、1階層下のプロジェクトだけを通します。「~/codeの直下のプロジェクトには移れるが、さらに奥のサブディレクトリには移れない」という運用になります。~/code自身にも移りたいならCd(~/code/**)を選びます。

組み合わせ例 — 許可リストとdenyの併用

個人の開発マシンで、作業用のリポジトリ置き場だけに移動先を絞る例です。

{
  "permissions": {
    "allow": ["Cd(~/code/**)"],
    "deny": ["Cd(~/code/private/**)"]
  }
}

~/code以下には移動できますが、~/code/private以下はdenyが先に効きます。許可リスト方式なので、~/Downloadsのような~/codeの外へ移ろうとした/cdは拒否されます。

/permissionsを開くと、セッションに効いているルールと、それぞれの出所の設定ファイルを一覧できます。意図したCdルールが読み込まれているかの確認に使えます。操作は/permissionsコマンドの記事にまとめています。

効く範囲と効かない範囲

Cdルールの守備範囲には、はっきりした境界があります。

permissions.blockReadsOutsideWorkingDirectoriesは作業ディレクトリ外の読み取りをブロックする記事で扱っています。

組織で/cdを止めたいときは、管理設定にCdのdenyを置きます。管理設定の権限ルールは、ユーザー設定やコマンドライン引数では上書きできません。管理設定だけを権限ルールの出所にするキーはallowManagedPermissionRulesOnlyの記事にあります。

置く場所ごとの書き分けとつまずきやすい点

どの設定にCdを書くかで、効き方が変わります。

つまずきやすいのは次の2点です。

• allowの照合は解決後の移動先に対して行われる。許可した場所の中に、外へ向かうシンボリックリンクがあっても、そのリンク経由では移れない
• 普段ほかの置き場のプロジェクトにも移るなら、その置き場もallowに加えておく。加え忘れると、そちらへの/cdが拒否される

Cdを絞ったあとの確認手順

ルールを入れたら、次の順で動作を確かめます。

まとめ

/cdは作業ディレクトリを変えるだけでなく、移動先のhooks・.mcp.json・envを現在のセッションへ持ち込みます。そのため、Cdルールは「どこを読ませるか」ではなく「どの設定をセッションに入れてよいか」を決めるルールとして使うと整理しやすくなります。固定したいなら裸のdeny、一部だけ塞ぐならパターン付きdeny、置き場を限るならallowによる許可リスト方式です。