/cd 跟 --add-dir 有什麼不同?為什麼不能用 --add-dir 取代 /cd?
這兩個指令解決的是不同性質的需求。--add-dir(以及對應的 /add-dir)是在你原本的工作目錄之外,「額外加入」一個新目錄,讓 Claude 能存取那個目錄裡的檔案——你的 session 主要工作目錄沒有改變,只是可以碰的範圍變大了。/cd 則是把整個 session 的主要工作目錄「搬過去」,原本的目錄不再是主要工作目錄。
這個差異也反映在設定套用的邏輯上:額外加入的目錄大部分不會被當成完整的設定來源,只有少數幾種類型的設定(例如 enabledPlugins、部分 CLAUDE.md 情境)會例外套用;而 /cd 移動到的新目錄,則會完整套用它自己的專案設定、hooks、MCP 伺服器、skills 跟 agents,就像你直接在那個目錄啟動一個全新 session 一樣。如果你的需求是「主要工作範圍整個換掉」,--add-dir 沒辦法達到跟 /cd 一樣的效果。
為什麼「換目錄」跟「新設定生效」中間曾經存在等待 resume 的落差,這個落差是怎麼造成的?
這反映的是 session 內部狀態(工作目錄本身)跟持久化設定載入流程(讀取專案設定、啟動 hooks、連接 MCP 伺服器)原本走的是不同的觸發路徑。移動工作目錄,本質上是改變 session 當下記得的一個路徑變數,這個改變本身可以立即發生,不需要太複雜的處理;但專案設定、hooks、MCP 伺服器這些東西,原本設計上是「session 啟動時」的一次性載入流程,而不是「session 執行過程中隨時可以重新觸發」的流程。
2.1.246 之前的行為,某種程度上反映了工作目錄的移動走了比較輕量的路徑,但完整的設定載入邏輯仍然只掛在 session 啟動這個時間點上——所以你换了目錄,只有目錄本身的改變是即時的,設定的重新載入還是得等到下一次真正意義上的「啟動」(也就是 resume)才會觸發。這次修正等於是把設定載入這個原本只在 session 啟動時觸發的流程,額外也接上 /cd 這個時間點,讓兩者不再需要透過重啟才能同步。
實際換目錄的時候,信任提示現在會顯示什麼,跟以前有什麼不同?
以前如果換到一個還沒信任過的目錄,系統會跳出信任提示,但這個提示沒辦法告訴你,一旦接受之後,那個目錄的設定實際上會啟用哪些東西——因為當時的設計裡,設定本來就要等 resume 才生效,提示本身自然也還沒有掌握完整的資訊可以列出來。
2.1.246 之後,信任提示會直接列出這個目錄的設定會啟用的允許規則、額外目錄、hooks、跟輔助指令,讓你在真正接受之前,就能看到完整的清單。如果看過清單之後決定不要接受,session 會留在原本的目錄,不會被強制搬過去——這代表現在的信任決策,是建立在你已經看過實際會發生什麼事的基礎上,而不是先接受、換過去之後才透過後續操作慢慢發現這個目錄的設定裡有些什麼。
如果我平常會在同一個 session 裡,用 /cd 在好幾個不同專案之間切換,這次修正對我實際的工作流程有什麼影響?
最直接的影響,是你不再需要為了讓新目錄的設定生效,刻意去中斷再恢復 session——過去如果你養成了「換目錄後先 resume 一次確保設定套用」的習慣,現在這個習慣其實可以省略,換目錄的當下設定就已經生效。
比較需要留意的實際差異,是舊目錄的專案層級跟 local-scope MCP 伺服器會在换目錄的當下就中斷連線,如果你原本習慣在切換之間讓某些背景連線保持運作(例如透過舊目錄的 MCP 伺服器持續監控某件事),現在這種連線會在換目錄的瞬間跟著中斷,不會像過去的行為那樣,因為設定本來就沒有即時套用而意外延續下去。如果你的工作流程依賴多個目錄之間同時保持某些連線,可能要重新設計成透過 --add-dir 額外加入目錄,而不是用 /cd 整個切換過去。
Claude Code 的 /cd 指令(2.1.169 版本開始提供)讓你可以在同一個 session 裡,把工作目錄換到另一個地方,同時保留原本的對話內容。2.1.246 這一版修正了一個從指令推出以來就存在的落差:過去換目錄之後,新目錄的專案設定、hooks、MCP 伺服器、skills,都要等你之後 resume 這個 session 才會真正套用;2.1.246 之後,這些設定會在你換目錄的當下就立刻生效。
/cd <path> 對應的情境,是你想把整個 session 的主要工作目錄搬到別的地方——不是像 --add-dir 那樣在原本的目錄之外「額外加一個」目錄,而是真的把整個 session 移過去。Claude Code 會保留對話紀錄,載入新目錄的 CLAUDE.md,如果這是你第一次在這個目錄工作,還會跳出信任提示。之後如果你要在新目錄用 --resume 恢復這個 session,系統也找得到它。
在這次修正之前,/cd 雖然會把工作目錄換過去,但新目錄底下的專案設定(包含其中的權限規則)、hooks、.mcp.json 裡設定的伺服器、skills,實際上並不會馬上套用到當下這個 session——你得先結束,再用 --resume 重新啟動,這些設定才會真正生效。這代表換目錄跟「這個目錄的設定真正開始作用」中間,有一段不容易察覺的空窗期,如果你換目錄之後直接開始操作,實際套用的可能還是舊目錄的設定組合,不是你以為已經切換過去的新設定。
修正之後,只要你一換目錄,新目錄的專案設定(含權限規則)、hooks、.mcp.json 裡的伺服器(仍然要經過一般的核准流程)、skills、agents 都會立刻生效,不需要中斷 session 再恢復。如果新目錄還沒被信任過,信任提示現在會列出這個目錄的設定實際會啟用哪些允許規則、額外目錄、hooks 跟輔助指令,讓你先看過內容再決定要不要接受——如果你選擇拒絕,session 會留在原本的目錄,不會被強制搬過去。
除了設定即時生效這個核心修正,/cd 換目錄時還有幾個原本就存在、值得一併了解的行為:額外目錄(additional directories)會改成採用新目錄設定裡列出的清單,但你用 --add-dir 或 /add-dir 手動加入的目錄會被保留下來,不會因為換目錄就消失;舊目錄底下、專案層級與 local-scope 的 MCP 伺服器會被中斷連線,換到的新目錄不再啟用的外掛所提供的伺服器也一樣;移動之後觸發的 hooks,拿到的 ${CLAUDE_PROJECT_DIR} 環境變數,指向的仍然是 session 一開始啟動時的專案根目錄,不會因為換了目錄而改變這個值。
如果你需要限制 /cd 的目標範圍,可以透過 Cd 這一類權限規則來設定——單純的 Cd 拒絕規則會直接停用整個 /cd 功能;如果是搭配路徑的拒絕規則,則是擋掉符合條件的目標目錄。只要加了任何一條 Cd 允許規則,/cd 就會切換成白名單模式,之後只有符合允許規則的目標目錄才能移動過去,沒有設定任何 Cd 規則的話,/cd 維持預設行為,對不熟悉的目錄照樣跳出信任提示。