VS Code 1.138 Codex 跨應用接管能直接給團隊用嗎？2026

你看到 ChatGPT 裡的 Codex 對話仍在，但 VS Code 可能連到錯誤工作區，甚至帶入不該有的工具權限。

最快解法：可以小範圍試點，但不要因為會話成功接續就直接全團隊開放；先完成會話、身份、權限、環境、交付與恢復六項驗收，長任務和 Xcode 交付優先放到隔離的遠端 Mac 或獨立工作樹。

這篇適合同時使用 ChatGPT 與 VS Code、希望不中斷 Codex 編碼會話的開發者，也適合需要治理模型訂閱、MCP、桌面應用和程式碼權限的平台工程師與安全負責人。準備讓 Codex 在遠端 Mac 持續執行並完成 Xcode 驗證的移動開發團隊，也應先看完再決定開放範圍。

先分清楚：會話接續不是環境接管

VS Code 1.138 已於 2026 年 9 月 16 日發布，官方說明列出擴展 Agent Host 的 Codex 支援，可在 ChatGPT 應用程式與 VS Code 之間繼續會話，並在符合條件時切換訂閱來源及重用桌面應用互動能力。這些資訊以VS Code 1.138 發布說明為準；截至 2026 年 9 月 19 日，功能仍可能逐步推送，並依帳戶、用戶端和設定而有差異。

對團隊而言，真正的風險不是「看不到上一句對話」，而是 Agent 看似接上後，實際附著到舊目錄、另一台主機或不同的批准狀態。常見失敗包括：

• 聊天歷史完整，但待批准的終端機動作消失，Agent 重新執行同一個命令。
• VS Code 視窗顯示同名倉庫，實際路徑卻是另一個 worktree，修改被寫入錯誤分支。
• 接管後多出終端機、MCP 或網路工具，團隊卻把這種新增能力誤認為原本權限。
• 遠端 Mac 仍在線，但 Xcode、環境變數、簽署身份或桌面視窗狀態已經改變。

因此，你要驗收的是「能否安全續跑」，不是「能否重新看到聊天」。

六項指標的放行分數：先比較風險，再決定試點

以下表格不是功能清單，而是把接管後的決策分成可保存的證據。任一高風險欄位無法證明時，都不要把結果當成團隊可用。

這種分數不是把六項平均計算。會話通過但工作區不通過，仍然應判定為不放行；權限通過但沒有恢復證據，也不能讓長任務無人看管。

VS Code 1.138 Codex 跨應用接管：聊天相同，執行責任可能不同

先從會話本身開始，並把「看得到」與「能續跑」分開驗證。接管前保存目前任務描述、最後一個已完成步驟、待批准動作和檔案變更摘要；接管後要求 Codex 說明它認為自己正在處理的任務，再與原始紀錄逐項比對。

官方的Codex harness 與訂閱切換說明涉及不同執行介面及訂閱來源。這代表你不能只記錄「Codex 已連線」，還要記錄模型由哪個訂閱提供，以及真正執行工具的是哪個 Agent Host。

如果出現連線中斷、重複執行、待批准動作遺失，最快的處置不是要求 Agent 自己猜測進度，而是：

1. 立即停止檔案寫入和終端機動作。
2. 保存當前差異、終端機輸出和會話識別資料。
3. 重新確認最後一個已驗證的提交或測試結果。
4. 從該狀態建立新的隔離任務，再恢復低風險操作。

這樣才能回答「誰發起任務、哪個訂閱提供模型、誰承擔工具執行責任」，而不是把所有責任歸給一段聊天紀錄。

訂閱切換與工具權限：可見上下文，不代表可用能力

Codex 的模型來源、聊天用戶端、Agent harness 和工具執行主機是不同層次。切換 Copilot 與 ChatGPT 訂閱後，即使上下文仍然顯示，模型選項、工具可用性和批准狀態也可能需要重新確認。你應把帳戶、訂閱和主機身份放在同一份接管紀錄中，禁止用個人帳戶登入後再讓團隊遠端主機執行。

接著盤點檔案編輯、終端機、擴充功能、MCP 和桌面應用能力。VS Code 的工具說明區分不同工具來源，而Agent Host 的工具路由文件說明部分工具可能由延伸功能主機處理。實務上的檢查順序應是：

• 接管前輸出實際可呼叫工具清單。
• 接管後在不修改檔案的情況下再次輸出清單。
• 比較是否新增檔案寫入、終端機、網路或桌面控制能力。
• 逐一確認 MCP 伺服器的命令、工作目錄、環境變數和可接觸的資料。
• 對照審批與權限管理文件，確認舊有批准沒有被錯誤帶入新場景。

MCP 設定尤其不能靠自然語言摘要驗收；應保存設定檔版本、伺服器啟動紀錄和一次實際拒絕測試。若跨應用後出現自動批准、新的網路存取或更寬的寫入範圍，先降回人工批准，再查明是帳戶、視窗、延伸功能還是 Agent Host 造成。

工作區與遠端主機：同名專案不等於同一份程式碼

你至少要保存倉庫提交、工作樹絕對路徑、分支、主機身份和未提交變更摘要。只看 VS Code 視窗標題、倉庫名稱或 ChatGPT 內的專案名稱都不夠，因為本地目錄、Dev Container、獨立 worktree 和遠端 Agent Host 可能各自有一份同名程式碼。

官方的程式碼隔離說明可作為選擇 worktree 或其他隔離方式的依據。對短時間、唯讀或可丟棄任務，本地工作區可以先試；只要任務會跨應用、持續執行、由多人接手，便應改用獨立工作樹。若還包含 Xcode 建置、模擬器或簽署流程，優先使用持續在線且權限獨立的遠端 Mac。

接管工作可以按以下順序操作：

1. 在原環境記錄提交、分支、絕對路徑和未提交檔案。
2. 建立獨立 worktree，或指定清楚的遠端 Agent Host 工作目錄。
3. 在 VS Code 確認主機身份、工作區路徑和目前提交。
4. 先要求 Codex 進行唯讀檢查，不允許修改和安裝依賴。
5. 對照接管前的任務狀態與工具清單。
6. 只批准一個可回復的小修改，保存差異和測試輸出。
7. 確認結果後才進入測試、PR 或 Mac 建置。

如果第 三 步的路徑、提交或主機身份無法與原紀錄吻合，就回退到重新開啟正確工作區，不要讓 Agent 透過檔名自行判斷。

桌面應用與 Xcode：能操作，不代表適合無人值守

VS Code 1.138 的相關說明提到，在符合設定條件時可重用桌面應用互動能力；但官方沒有因此確認所有帳戶、桌面應用或任務都具備一致支援，也沒有給出完整企業審計、全自動恢復或無人值守安全保證。你應以Codex 跨應用接續說明核對目前條件，不要把「可以接續」延伸解讀成「可以自動發布」。

桌面操作可分成三層：

• 唯讀查看：查看 Xcode 專案、建置設定或測試結果，先驗證主機與工作區。
• 可回復編輯：修改程式碼或專案設定，但保留差異、提交和回退方式。
• 外部副作用：簽署、上傳、發布、修改敏感帳戶或操作憑據，必須人工批准。

每次桌面操作都要保存系統日誌、命令輸出、檔案差異或建置產物，不能只接受 Codex 的文字總結。若桌面應用視窗被切換、主機重啟、環境變數改變，原本的批准狀態也應視為失效。

長任務的放行條件：滿足才擴大，否則回到個人試用

按下面的分支做決策，不要用「目前看起來正常」作為團隊放行理由：

• 若會話狀態、訂閱來源、工具清單、工作區路徑和主機身份都能保存並前後吻合，且完成一次可回復修改，則可讓少量開發者進行受限試點。
• 若任一工具權限在接管後變寬，或 MCP、終端機和桌面操作沒有人工批准，則回退到唯讀驗證與人工執行。
• 若任務需要持續在線、多人接手或使用 Xcode，則選擇隔離 worktree 加遠端 Mac；不要把共享本地視窗當成長任務執行環境。
• 若斷線、主機重啟、批准超時和錯誤工作區接管都能停止、恢復或回退，則才考慮擴大至團隊限量開放。
• 若只有聊天紀錄可見，卻沒有檔案差異、建置結果、測試輸出或恢復紀錄，則暫緩部署。

你可以先參考MacPull 的支援與操作說明，把遠端主機身份、工作區路徑和交付產物納入團隊值班紀錄；需要評估不同遠端 Mac 方案時，再查看MacPull 的方案資訊。

最後判斷：目前方案與 Mac 方案，差別在可驗證的交付環境

如果你把跨應用接管留在本地共享電腦上，長任務容易受睡眠、斷線、使用者視窗切換和本地權限污染影響；遇到 Xcode、模擬器或簽署流程時，還可能缺少持續在線的桌面環境。這些限制不是會話同步能解決的，也會讓錯誤工作區和未完成建置更難追蹤。

完成六項驗收後，若你的任務只是短時間、低權限和可回復修改，本地試點仍然合理；若需要讓 Agent 長時間執行、由多人接手，或必須完成 Xcode 真實建置，隔離的 Mac 執行環境通常更容易保存主機身份、工作樹、日誌與交付證據。你可以先從 MacPull 的遠端 Mac 方案了解可用環境，再依任務持續時間決定是否租用；重點不是把所有工作搬到雲端，而是讓每一次 Codex 接管都有清楚的邊界和可回退結果。

常見問題