Codex Desktop 瀏覽器工具連不上：先分流登入、擴充功能與啟動錯誤

先確認你需要的是哪一種瀏覽器能力#

Codex 的瀏覽器工作不只一種入口。若任務只需要開啟公開頁面、閱讀內容或測試本機網站，內建 Browser 可以是合理起點；若任務依賴你既有的 Chrome 分頁、登入 session 或擴充功能，才需要改用 Chrome 整合。

這個區分很重要，因為「Threads 顯示登入」只證明目前瀏覽器沒有可用 session，不等於 Browser 工具無法啟動；反過來，Chrome 擴充功能無法連線，也不代表內建 Browser 必定故障。每次測試只選一個入口與一個公開網址，才能讓結果可比較。

用三段式測試把故障位置找出來#

先做第一階段，再做第二階段。若連新分頁都無法建立，繼續切換網站或重新登入不會增加有效資訊。若公開頁面可用、只有特定服務要求登入，問題已經縮小到該瀏覽器的 session 或服務端授權流程。

出現啟動例外時，先保留能重現的最小證據#

公開 issue 中有人回報 Browser 與 Chrome 整合在載入 client 前就出現 Cannot redefine property: process。這是特定 App、插件與 macOS 組合的使用者回報，不是官方公告的通用診斷結論；真正有用的是把自己的失敗點記成可比對的資料。

可以整理成這個格式，並移除帳號、cookie、token、專案路徑與私人網址：

1
測試日期：2026-07-15
2
Codex App / build：
3
Browser 或 Chrome 插件版本：
4
macOS 版本與架構：
5
入口：內建 Browser / Chrome 整合
6
最小動作：啟動工具、建立分頁、開啟公開網址
7
結果：成功 / 失敗
8
完整錯誤訊息：

若錯誤在載入整合時就發生，這份紀錄比「某網站打不開」更有辨識力；若錯誤只在登入後出現，則要另外記下服務名稱與授權畫面的狀態，而不是把機密內容貼進 issue。

不要把重裝當成第一個動作#

重裝 App、重新安裝插件或重設 Chrome 都可能改變狀態，但也會抹掉原本可比較的線索。比較穩的順序是：

1. 固定一個入口，先完成公開頁面的最小測試。
2. 記錄 App、插件、macOS 版本與錯誤發生階段。
3. 對照官方 Codex 文件確認該工具是否本來就需要既有 Chrome session 或特定擴充功能。
4. 再查看公開 issue 是否有相同的錯誤字串與相近版本；把它當成參考，不當作修復指令。
5. 只有在已保存版本與錯誤證據後，才逐一嘗試更新或重新安裝，且每次只改一項。

這個順序也適合回報問題：維護者能判斷是安裝失敗、session 缺失，還是啟動期相容性，而不是收到一串已做過但無法重現的操作。

不要上傳瀏覽器資料

排查瀏覽器整合時，請不要提供 cookie、local storage、密碼、一次性驗證碼、完整瀏覽紀錄或 API key。支援人員通常需要的是版本、最小重現步驟與經過遮罩的錯誤輸出。

下次遇到「連不上」時的判斷點#

先問「它在哪一段失敗？」比先問「要不要重裝？」更快。能建立分頁但需要登入，是 session 問題；能開公開頁面但 Chrome 整合失敗，是既有 Chrome 狀態或擴充功能問題；連工具初始化都失敗，才應把焦點放在版本、啟動期錯誤與可重現的 issue。

常見問題#