CC Switch 修改不生效，最常見原因不是「沒有儲存」，而是你查看的檔案、正在執行的客戶端與 CC Switch 寫入的 live config 並非同一份。不要先刪設定；先找出目前真正生效的設定來源。
先分清三類設定
- CC Switch 自身資料：Provider、同步、備份與管理紀錄。
- 目標工具 live config：Claude Code、Codex 等實際啟動時讀取的設定。
- 專案級設定：某個儲存庫專用的 MCP、環境變數或說明檔，可能優先於使用者級設定。
CC Switch 的目標是寫入或回填目標工具的 live config，但不同工具、系統與版本的實際路徑可能改變。不要照抄網路上的固定目錄；優先在 CC Switch 目前選取的工具頁查看它管理的對象，再用目標 CLI 的設定輸出或日誌交叉確認。
修改後仍不生效的排查順序
- 在 CC Switch 確認目前 Provider、MCP 或 Skill 已儲存，且切換的是正確工作區。
- 完全結束目標 CLI 與相關終端，再重新啟動。許多 CLI 不會熱載入 Provider 設定。
- 檢查專案目錄是否有覆蓋使用者級設定的設定檔或環境變數。
- 查看 MCP 服務本身日誌，確認不是「已載入設定但服務啟動失敗」。
- 若開了雲端同步，確認另一台裝置沒有回寫舊版本。
不要手改後又讓同步覆蓋
排障時可備份後對比設定，但避免同時在 CC Switch、文字編輯器與同步磁碟裡改同一份內容。較穩的做法是：暫停同步，匯出或備份目前設定，做一次最小修改，重啟並驗證後再恢復同步。
API key、MCP 命令與本機路徑都可能敏感，分享截圖或日誌前應遮蔽。Provider、雲端同步與備份可回看 CC Switch 使用教學；若 MCP 呼叫本身回傳錯誤，請按 MCP 工具呼叫失敗排查繼續定位。
總結
CC Switch 修改不生效時，依序確認「寫到哪裡、誰在覆蓋、程序是否重啟、服務是否啟動」。先做最小驗證，比全量重裝或刪除設定更安全。
先做設定來源清單
排錯前列出所有可能影響結果的來源：CC Switch 目前設定、目標客戶端使用者級設定、專案目錄設定、終端環境變數、系統環境變數與雲端同步副本。不要假設「最後編輯的檔案就是最後生效的檔案」；許多 CLI 在啟動時讀取環境變數，而專案設定又可能覆蓋使用者級設定。
| 項目 | 記錄內容 |
|---|---|
| 目前客戶端 | 名稱、版本、啟動方式 |
| 目前工作區 | 儲存庫根目錄、是否受信任 |
| Provider | Base URL、模型別名，不記完整金鑰 |
| MCP | server 名稱、命令、啟動日誌位置 |
| 同步 | 是否開啟、最後同步裝置 |
Provider 沒切換時怎麼查
先用目標客戶端的請求日誌或服務端日誌確認它實際存取的 endpoint。若仍是舊位址，問題在設定寫入、覆蓋或程序未重啟；若已是新位址但失敗，繼續檢查新 Provider 的 key、模型名與服務狀態。分開這兩類問題，可避免在錯誤層面反覆修改。
也要注意多個終端視窗：已執行的 shell 可能保留舊環境變數，即使 CC Switch 已更新系統設定也不會自動刷新。關閉舊終端，開啟乾淨視窗並做最小請求測試。
MCP 修改不生效時怎麼查
MCP 有「客戶端是否讀取設定」與「server 能否啟動」兩道門。工具清單中看不到該 server，表示設定未被讀取或格式無效；看得到但呼叫失敗，則查看 server 的啟動命令、工作目錄、依賴、連接埠與 stderr 日誌。
Windows 上含空格的路徑、巢狀引號、Node/Python 直譯器不在同一環境，都是常見原因。不要將未測試的長 shell 命令直接塞進設定；先在同一終端獨立執行成功。
如何安全恢復
若設定已混亂，先匯出或複製可讀版本，再暫停雲端同步。接著只刪除「確定由 CC Switch 管理的測試項」，不要動無關工具設定；建立一個新 Provider 或簡單 MCP server，驗證寫入、重啟與呼叫完整鏈路，再逐步匯入舊內容。
FAQ：能直接刪除所有設定目錄嗎？
不建議。這會遺失金鑰引用、MCP 設定、工作階段與難以重建的專案偏好。先備份、確認設定歸屬，再做範圍最小的恢復。
FAQ：為什麼不同電腦切換結果不一樣？
優先檢查同步版本、客戶端版本與系統環境變數。同步只保證檔案複製，不保證兩台裝置有相同本機模型、路徑、可執行程式與權限。