Bible Network Crypto DeFi Onchain RWA AI Agent Stablecoin Chain SAFU CryptoTax DeFAI AGI Claude Me Claude Skill Claude Design Claude Cowork
独立メディア
いかなるプロジェクトとも無提携
AI知性のフロンティアを探求する
claude-me.com
最新
Claude Codeに--restrictedモードが追加:見知らぬプロジェクトのための最小権限の出発点  ·  Claude Codeの`/cd`コマンドが修正:ディレクトリ移動後、新しいディレクトリの設定が即座に反映され、resumeを待つ必要がなくなった  ·  Claude Codeに起動時警告が追加:`Bash(git * main)`という書き方は、想定よりはるかに広い範囲にマッチする  ·  Claude Codeの--worktreeがGitLabのマージリクエストURLを直接受け取れるように、番号への変換は不要  ·  Claude Code Remote Controlにライブストリーミングが追加:フォアグラウンドsubagentのすべてのツール呼び出しがスマホで見られる  ·  Claude CodeにPreModelSwitch/PostModelSwitchフックが追加:モデル切り替えがついに検知・記録できるように
practice

Claude Codeの`/cd`コマンドが修正:ディレクトリ移動後、新しいディレクトリの設定が即座に反映され、resumeを待つ必要がなくなった

30秒バージョン · 忙しい方へ
ディレクトリを移動したことと、新しい設定が実際に効き始めることの間には、かつて空白期間があった——切り替わったと思っていても、実際にはまだ古いディレクトリのルールで動いていたということだ。

詳しく読む +
01 · なぜ起きたのか?

/cd--add-dirは何が違うのか?なぜ--add-dir/cdの代わりにならないのか?

この2つのコマンドは異なる性質のニーズに対応している。--add-dir(および対応する/add-dir)は、既存の作業ディレクトリに加えて新しいディレクトリを「追加」し、Claudeがそのディレクトリ内のファイルにもアクセスできるようにする——セッションの主要な作業ディレクトリは変わらず、アクセスできる範囲が広がるだけだ。一方/cdは、セッション全体の主要な作業ディレクトリを別の場所に「移動」させるもので、元のディレクトリはもはや主要な作業ディレクトリではなくなる。

この違いは設定の適用ロジックにも表れている。追加されたディレクトリは、ほとんどの場合完全な設定の出所とは見なされず、ごく一部の種類の設定(enabledPluginsや一部のCLAUDE.mdのケースなど)だけが例外的に適用される。一方、/cdで移動した新しいディレクトリは、そのディレクトリ自身のプロジェクト設定、hooks、MCPサーバー、skills、agentsを完全に適用する。まるでそのディレクトリで直接新しいセッションを開始したかのようにだ。もしニーズが「主要な作業範囲を丸ごと入れ替える」というものであれば、--add-dirでは/cdと同じ効果を得ることはできない。

02 · 仕組みは?

なぜ「ディレクトリを移動すること」と「新しい設定が有効になること」の間に、resumeを待つというギャップがそもそも存在していたのか、このギャップは何が原因だったのか?

これは、セッション内部の状態(作業ディレクトリそのもの)と、永続的な設定の読み込みプロセス(プロジェクト設定の読み込み、hooksの起動、MCPサーバーへの接続)がもともと異なるトリガー経路を辿っていたことを反映している。作業ディレクトリの移動は、本質的にはセッションが現在記憶しているパス変数を変更することであり、この変更自体は複雑な処理を必要とせず即座に起こりうる。しかしプロジェクト設定、hooks、MCPサーバーといったものは、もともと「セッション起動時」に一度だけ読み込まれるプロセスとして設計されており、「セッション実行中にいつでも再トリガーできる」プロセスではなかった。

2.1.246以前の挙動は、ある意味で、作業ディレクトリの移動がより軽量な経路を辿っていた一方で、完全な設定読み込みロジックは依然としてセッション起動というタイミングにのみ紐づいていたことを反映している。そのためディレクトリを移動しても、ディレクトリ自体の変更だけが即座に反映され、設定の再読み込みは次の本当の意味での「起動」(つまりresume)を待たなければトリガーされなかった。今回の修正は、もともとセッション起動時にのみトリガーされていた設定読み込みプロセスを、/cdというタイミングにも追加で結びつけたことに等しく、両者がもはや再起動を介さなくても同期できるようになった。

03 · 自分にどう影響する?

実際にディレクトリを移動する際、信頼確認プロンプトは今何を表示するようになり、以前と何が違うのか?

以前は、まだ信頼されていないディレクトリに移動すると、システムは信頼確認プロンプトを表示していたが、そのプロンプトは、一度受け入れた場合にそのディレクトリの設定が実際に何を有効化するのかを教えてくれなかった——当時の設計では、設定はどのみちresumeを待って初めて有効になっていたため、プロンプト自体もそもそも一覧表示できるだけの完全な情報をまだ持っていなかったからだ。

2.1.246以降、信頼確認プロンプトは、そのディレクトリの設定が有効化する許可ルール、追加ディレクトリ、hooks、ヘルパーコマンドを直接一覧表示するようになり、実際に受け入れる前に完全なリストを確認できるようになった。リストを確認した後、受け入れないことを決めた場合、セッションは元のディレクトリに留まり、強制的に移動させられることはない——つまり今の信頼の判断は、実際に何が起きるかを既に確認したうえで下されるものになっており、まず受け入れて移動してから、その後の操作を通じてそのディレクトリの設定に何が含まれていたかを徐々に発見していく、というものではなくなった。

04 · どうすればいい?

もし普段から同じセッション内で/cdを使って複数の異なるプロジェクトを切り替えている場合、今回の修正は実際のワークフローにどう影響するのか?

最も直接的な影響は、新しいディレクトリの設定を反映させるために、わざわざセッションを終了してresumeし直す必要がなくなったことだ——もし「ディレクトリを移動した後、念のため一度resumeして設定が適用されるようにする」という習慣が身についていたなら、今やその習慣は省略できる。ディレクトリを移動した瞬間に、設定は既に有効になっているからだ。

より実務上注意すべき違いは、古いディレクトリのプロジェクトスコープおよびローカルスコープのMCPサーバーが、ディレクトリを移動した瞬間に接続を切断されるようになったことだ。もしワークフローが、切り替えの間もバックグラウンドの接続を維持し続けることに依存していた場合(例えば古いディレクトリのMCPサーバーを通じて何かを継続的に監視するなど)、こうした接続は今やディレクトリを移動した瞬間に一緒に切断されてしまい、以前のように設定がそもそもリアルタイムで適用されていなかったために意図せず存続してしまう、ということはなくなった。もしワークフローが複数のディレクトリにまたがって特定の接続を同時に維持することに依存しているなら、/cdで丸ごと切り替えるのではなく、--add-dirでディレクトリを追加する方式に設計し直す必要があるかもしれない。

全文 +

Claude Codeの/cdコマンド(バージョン2.1.169から利用可能)は、会話を保持したまま、セッションの作業ディレクトリを別の場所に移動させることができる。2.1.246では、このコマンドが登場して以来存在していたギャップが修正された。これまでは、ディレクトリを移動した後、新しいディレクトリのプロジェクト設定、hooks、MCPサーバー、skillsは、後でセッションをresumeして初めて実際に適用されていた。2.1.246以降は、移動した瞬間にこれらが適用されるようになった。

`/cd`がそもそも解決しようとしていた問題

/cd <パス>が対応するのは、セッション全体の主要な作業ディレクトリを別の場所に移したい場面だ——--add-dirのように現在のディレクトリに「もう一つ追加する」のではなく、セッション全体を本当に移動させる。Claude Codeは会話履歴を保持し、新しいディレクトリのCLAUDE.mdを読み込み、そのディレクトリで作業するのが初めてであれば信頼確認のプロンプトを表示する。その後、新しいディレクトリから--resumeでこのセッションを復元したい場合も、システムはそれを見つけられる。

2.1.246以前:ディレクトリ移動後、新しい設定はresumeを待つ必要があった

今回の修正以前は、/cdは作業ディレクトリを移動させはするものの、新しいディレクトリ配下のプロジェクト設定(その中の権限ルールを含む)、hooks、.mcp.jsonで設定されたサーバー、skillsは、実際には今のセッションにすぐには適用されなかった——一度終了し、--resumeで再起動して初めて、これらの設定が本当に有効になっていた。つまり、ディレクトリを移動したことと、そのディレクトリの設定が実際に効き始めることの間には、気づきにくい空白期間があったということだ。もしディレクトリを移動した直後に操作を始めてしまうと、実際に適用されているのは、切り替わったと思っていた新しい設定ではなく、まだ古いディレクトリの設定の組み合わせだった、ということになりかねない。

2.1.246以降:ディレクトリ移動の瞬間に新しい設定が適用される

修正後は、ディレクトリを移動した瞬間に、新しいディレクトリのプロジェクト設定(権限ルールを含む)、hooks、.mcp.jsonのサーバー(依然として通常の承認プロセスを経る)、skills、agentsがすべて即座に有効になり、セッションを中断してresumeし直す必要がなくなった。新しいディレクトリがまだ信頼されていない場合、信頼確認プロンプトは今や、そのディレクトリの設定が実際に有効化する許可ルール、追加ディレクトリ、hooks、ヘルパーコマンドを一覧表示し、内容を確認してから受け入れるかどうかを決められるようになった。拒否を選んだ場合、セッションは元のディレクトリに留まり、強制的に移動させられることはない。

ディレクトリ移動と同時に調整される他の要素

設定が即座に反映されるというこの中核的な修正に加えて、/cdによるディレクトリ移動には、元々存在していて一緒に知っておく価値のあるいくつかの挙動がある。追加ディレクトリ(additional directories)は新しいディレクトリの設定に記載されたリストに切り替わるが、--add-dir/add-dirで手動追加したディレクトリは保持され、ディレクトリを移動したからといって消えることはない。古いディレクトリ配下のプロジェクトスコープおよびローカルスコープのMCPサーバーは接続が切断され、新しいディレクトリでもう有効になっていないプラグインが提供するサーバーも同様だ。そして移動によってトリガーされるhooksは、依然としてセッションが最初に開始されたプロジェクトルートを指す${CLAUDE_PROJECT_DIR}環境変数を受け取る——この値はディレクトリを移動したからといって変わることはない。

`/cd`が移動できる場所を制限したい場合

/cdが移動できる範囲を制限する必要がある場合は、Cdというカテゴリーの権限ルールを通じて設定できる。単純なCd拒否ルールは/cd機能全体を直接無効化する。パスを伴う拒否ルールであれば、条件に合致する対象ディレクトリをブロックする。Cd許可ルールを一つでも追加すると、/cdはホワイトリストモードに切り替わり、以降は許可ルールに合致する対象ディレクトリにのみ移動できるようになる。Cdルールをまったく設定していない場合、/cdはデフォルトの挙動を維持し、見慣れないディレクトリに対しては引き続き信頼確認プロンプトを表示する。

出典:Configure permissions - Claude Code DocsRelease v2.1.246 - anthropics/claude-code
図解
/cd 修正前後對比2.1.246 之前換目錄後設定要等 resume 才生效,之後則是換目錄的當下就立即套用,信任提示同步列出會啟用的內容/cd: Before vs After 2.1.246Before/cd moves directoryinstantlySettings/hooks/MCP waitfor --resume to applyEasy-to-miss gapAfter (2.1.246+)/cd moves directoryinstantlySettings/hooks/MCP applyimmediately, no resume neededTrust prompt lists what activatesClaude Me · claude-me.com
スクリーンショット歓迎。転載時は出典を明記してください。
質問する
10文字以上入力してください
関連記事
Claude Codeに--restrictedモードが追加:見知らぬプロジェクトのための最小権限の出発点
practice · 09/04
Claude Codeに起動時警告が追加:`Bash(git * main)`という書き方は、想定よりはるかに広い範囲にマッチする
practice · 09/04
Claude Codeの--worktreeがGitLabのマージリクエストURLを直接受け取れるように、番号への変換は不要
practice · 09/02
Claude CodeのAuto Modeが8月14日からデフォルトに、ルールは今や平易な文章で書けるように
practice · 09/01
関連ニュース
関連トピック