Codex CLI 0.169 更新：多側邊對話、自訂提供者與專案信任修正，怎麼分開看？
Codex CLI 0.169 新增多側邊對話、舊任務搜尋與自訂提供者，並修正專案信任。整理啟用條件、本機診斷與 Cloud 範圍，說明聊天和檔案隔離差異。
同時處理程式修改、查資料與追蹤舊任務時，終端機裡的對話很容易混在一起。工具若只能增加新聊天，卻找不回之前的工作，仍會增加交接成本。
OpenAI 在 2026 年 11 月 13 日發布 Codex CLI 0.169 正式版，更新多側邊對話、舊任務搜尋與自訂模型提供者，並修正未信任目錄的設定載入行為。
Codex CLI 是在本機終端執行的程式代理。這次有些功能需要選擇啟用，另一些只適用特定系統，不能把版本更新當成所有使用入口已同步開放。
工作區提供多個側邊對話，讓開發者切換和找回脈絡；提供者設定則決定請求走向哪個服務。兩者解決的問題不同，也不會自動替檔案修改建立隔離。
我會建議先把工作組織與信任設定分開驗證。聊天切換更方便之後，專案能載入哪些設定、哪一個閘道拿到請求，仍應有明確邊界。
要安排升級，可以先看哪些能力會改變日常工作，再確認需要啟用的條件。尤其多個聊天視窗，和多份彼此隔離的程式工作目錄，是兩件事。
多側邊對話幫助分流，沒有自動隔離檔案
選擇啟用的終端工作區可開多個側邊對話，並重新開啟保存的本機對話。這讓查文件、討論測試與主要修改工作有各自的紀錄，不必把每個岔出去的問題都塞回同一段聊天。
側邊對話可以用編號分頁切換，也能用滑鼠選取。版本相關的官方修改說明指出，切換時會保留對話草稿、紀錄與版面狀態。重要的變化是能回到原本的支線，而不只是開出更多暫時視窗。
例如，主要對話正在修一個匯入功能，另一個對話可以先解釋現有測試的意義。這是整理討論的方法，並不表示兩個對話操作的檔案天然分開。如果都在同一個工作目錄修改同一個檔案，仍可能互相影響。
需要平行修改的團隊，應另外安排獨立工作目錄或版本控制的工作樹。工作樹是從同一份版本庫建立另一份工作檔案，解決的是檔案狀態隔離。側邊聊天解決的是對話脈絡。兩者可以搭配，卻不能互相取代。
保存的側邊對話也有生命週期。官方修改說明區分關閉分頁、封存與刪除父對話：關閉後仍能從選擇器找回，封存會從側邊列表移除，刪除父對話則會一併刪除相關側邊對話。
因此，清理頁籤前要先分清自己是在收起畫面，還是在移除工作紀錄。對話分開後，找回舊工作與閱讀長紀錄也需要相應工具。
舊任務搜尋與折疊紀錄，讓脈絡比較容易找回
命令中心搜尋與活動折疊，分別處理任務定位和長紀錄閱讀。前者幫你找出要接續哪個任務，後者讓已找到的任務比較容易閱讀。
這次搜尋可利用任務名稱、提示內容預覽與工作目錄定位舊工作。工作目錄特別實用：兩個專案都可能討論「登入失敗」，只看相似標題不容易分辨，搭配目錄才能知道哪一個才是要恢復的紀錄。
找到任務之後，仍要先確認它指向的檔案狀態。舊對話記得當時的推理，不代表目前程式沒有被其他人改過。重新接續時，可以先讓代理讀取現況並確認差異，再沿用之前的計畫。
全螢幕介面則新增折疊已完成活動的設定。工具呼叫細節可以收起，答案仍留在畫面。原本的工具輸出也保留搜尋能力。這是在減少閱讀干擾，沒有刪除執行證據。
對應設定 tui.collapse_turn_details 預設停用，使用者可以依閱讀習慣選擇。若正在追查失敗原因，展開工具紀錄可能更有幫助。若只是回顧結論，折疊後比較容易看出每輪完成了什麼。
這兩項功能共同降低找回脈絡的成本，但不會替你判定舊結論是否仍有效。工作在哪裡延續確定後，還要知道模型請求會送往哪裡。
自訂提供者與裝置代碼，仍有支援及授權條件
新版本可從終端新增或編輯提供者，特定閘道則可使用裝置代碼完成登入。提供者是實際接收模型請求的服務設定，包含服務位置與對應的認證方式。
自訂提供者的管理入口，讓需要不同模型服務的開發者少一些手動設定工作。不過，介面能建立設定，並不代表任意網址都能提供 Codex 所需的全部能力。相容性、模型功能與服務授權仍要各自確認。
官方也改善自訂閘道的首次設定流程，並讓支援的閘道使用裝置代碼登入。這類流程適合透過遠端連線操作終端、當下沒有本機瀏覽器的情境：在可用的裝置完成認證，再讓原終端取得授權結果。
「沒有本機瀏覽器」不等於「不用登入」。認證仍必須由支援的服務完成，帳號能用哪些模型也受該入口條件限制。不能只因看到裝置代碼選項，就認為所有自訂提供者都支援相同登入方式。
團隊評估時可以先記下目前使用的提供者、模型與工作目錄，再做一個不涉及外部變更的簡單請求。若回應與預期不同，就能先檢查服務設定，而不是在多個聊天同時工作時才追查請求去了哪裡。
連線方式改變後，專案本身的設定來源仍需另外信任。遠端服務的登入狀態，不能替工作目錄中的設定背書。
專案信任與沙盒，控制的是不同範圍
未信任目錄的專案設定與 MCP 伺服器，會持續停用直到明確建立信任。MCP 是讓代理連接外部工具與資料來源的協定，專案若自行宣告伺服器，會影響代理能接觸的工具。
這次修正明確保留這條界線：即使以允許寫入工作區的沙盒模式執行，也不能因此載入尚未信任的專案設定與 MCP。沙盒處理程序可以讀寫或存取哪些範圍，專案信任則處理要不要採納這個目錄提供的設定。
兩項控制回答不同問題。允許代理修改檔案，不代表目錄裡每一份工具設定都已經被認可。同樣地，信任專案設定，也不能被理解成撤除所有執行限制。
版本新增讓執行與審查流程以 --trust 明確保存專案信任的能力。這是建立信任的操作，不宜當成遇到錯誤就加上的通用修復參數，更不應在持續整合流程中為了讓任務通過而習慣性加入。
若升級後發現工具沒有出現，合理的排查順序是先看目前目錄與信任狀態，再核對專案設定是否應被採納。不要直接改成更寬鬆的權限，否則可能掩蓋原本真正需要處理的設定問題。
了解這個修正，才不會把連線或工具缺少的原因全推給模型。便利的工作組織功能，仍建立在清楚的設定來源之上。
診斷 ZIP 與 Cloud 連線，分清本機保存與外傳
報告編輯器可把診斷包留在本機，Cloud 連線則有獨立的選擇啟用與平台條件。兩者都涉及任務資料，但用途和資料流向不同。
在報告編輯器按下 Ctrl+S，可以保存本機診斷 ZIP，即使上傳功能停用也可使用。這有助於先留住排查資料，再決定後續如何處理。產生檔案本身不等於已把資料傳給服務端。
需要分享診斷資料時，仍應確認檔案內容與接收對象。對含有內部程式或專案路徑的工作，先保存再檢查，比只看到「報告已建立」就假設所有後續步驟都完成更容易管理。
Cloud 連線則是另一條選擇啟用的功能，本版說明範圍為 macOS 與 Linux，包含圖片、模型與推理程度設定，以及任務封存和恢復。這不能直接推論 Windows 或其他 Codex 入口已取得同樣能力。
此外，核准計畫後交接到新脈絡時，系統會帶入完整計畫。交接失敗則保留目前工作階段。對使用者而言，應確認任務究竟成功交到新對話，還是仍留在原來的位置，避免在兩處重複安排相同工作。
升級驗收需要按功能分類，才能知道資料與狀態有沒有走對路。診斷保存、雲端接續與本機多對話，應各自留下清楚結果。
先驗原本工作，再逐項啟用新能力
先用低風險專案核對搜尋、對話與設定載入，較容易辨認版本變動造成的差異。若一開始就同時更換提供者、開多個對話又改信任設定，失敗時很難定位是哪一項造成。
第一輪可以保留原本服務與目錄，只測一項既有任務是否能正常恢復。再開一個側邊對話，確認切換後草稿與紀錄仍在，關閉分頁後也能按預期找回。
第二輪才檢查設定來源：在未信任目錄確認專案設定沒有被意外載入。對已審核的專案，再依團隊既有程序建立信任。這是在驗證設定界線，不需要為了測試執行真正的對外操作。
最後才比較新增提供者或 Cloud 連線的行為。每一步保留版本、系統、目錄與結果，遇到差異就有足夠背景回報。便利性改善可以逐步採用，不必一次改變整套工作方式。
升級紀錄要能指出差異發生在哪一層
測試紀錄可以採同一個簡單任務，分開記錄找到舊對話、讀取檔案、提出修改與恢復工作四個結果。若搜尋成功但開啟了另一個目錄，就不是模型回答品質問題。若對話正確但工具沒載入，則應回頭檢查信任與設定。
這樣安排也能降低回報成本。描述「更新後不能用」很難重現，保留系統、版本、任務入口與具體失敗步驟，才容易判斷是否與本版修正有關。需要診斷時，再利用本機保存的檔案補充證據。
對多人專案，可另外記下任務恢復時的版本控制狀態。舊任務提到的檔案若已改名，代理需要先辨認現況，不能直接重播舊步驟。搜尋與對話保存讓脈絡更容易回來，現況核對則避免把過期假設帶回程式。
完成這幾項基本檢查後，再決定哪些新功能納入日常。如此一來，未來再升級時已有可比較的基準，而不是每次從零判斷介面變化。
Codex CLI 0.169 常見問題
更新後會自動啟用所有新介面嗎？
不會。本版有需要選擇啟用的終端工作區與 Cloud 連線，也有預設停用的活動折疊設定。應依實際入口確認，不把發布說明當成所有功能已開啟。
側邊聊天可以代替獨立工作樹嗎？
不行。聊天分開保存討論，工作樹分開保存檔案狀態。若多個任務要同時修改程式，仍要安排檔案層的隔離與整合方式。
保存診斷 ZIP 會立即上傳嗎？
本次新增的是本機保存能力，停用上傳時仍可建立。是否傳出資料是後續獨立動作，分享前可先檢查實際檔案。
使用 --trust 等於取消沙盒嗎？
不等於。它明確保存專案信任，不能概括成撤除所有限制，也不應作為遇到持續整合錯誤時的預設處理方式。
已有 CLI 使用者可以先核對版本與工作目錄，再逐項評估是否啟用。讓對話容易找回、請求去向清楚，而且設定來源可解釋，這次更新才會實際減少日常交接負擔。
延伸閱讀：Codex CLI 0.166 更新：任務放進佇列後接著做，連線問題先用 doctor 找原因
延伸閱讀：OpenAI Agents 開發接口是什麼？從 Computer use 到多代理編排的完整指南
