Codex 怎麼安裝？Windows／Mac 下載設定與 CLI 安裝指南

想把 Codex 裝起來，第一個要做的決定與其說是選哪個指令，更精確地說是選路線。OpenAI 在 2026 年 9 月的官方文件裡，把 Codex 的安裝分成四個入口：桌面 App、CLI 命令列工具、IDE 擴充功能，以及完全不必安裝的雲端版。Windows 與 Mac 的下載位置、CLI 的三種安裝法、登入與驗證、裝完之後的健檢指令，這篇一次整理清楚，所有指令與方案資訊都以官方文件在 2026 年 9 月 27 日的內容為準。

行文順序先幫你把四個入口的分野畫清楚，列出安裝前該確認的三件事，接著是桌面 App 的下載與設定（含 Windows 原生沙盒與 WSL2 兩種模式）、CLI 的三種安裝法與系統需求、IDE 擴充功能的安裝、雲端版的零安裝設定，然後進入第一次啟動的登入流程與身分驗證細節、codex doctor 健檢、常見安裝問題排解、方案門檻與費用、解除安裝的乾淨移除，收尾給一套依工作習慣選路線的判斷。安裝類資訊的半衰期很短，官方每週都在推更新，動手前建議對照官方文件再確認一次。

先分清楚：你要安裝的是哪一個 Codex

搜尋「Codex 安裝」會出現好幾種教學，有的教你在終端機打 npm 指令，有的叫你下載桌面 App，還有人直接叫你打開瀏覽器就能用。這些說法都對，因為它們安裝的是不同的入口，接到的是同一個代理引擎。官方文件目前列出四個入口：ChatGPT 桌面 App、Codex CLI、IDE 擴充功能、Codex 雲端。四者的能力與方案門檻不同，選錯入口的挫敗感，通常與工具好壞無關，問題出在那個入口跟你的工作方式不合。

雲端版嚴格說不算「安裝」，但把它放進來是必要的：打開 ChatGPT 的 Codex 頁面、登入帳號、連上 GitHub 或 GitLab 儲存庫，任務就在 OpenAI 管理的隔離環境裡跑，本機什麼都不用裝。很多人的第一個 Codex 任務其實從雲端開始最省事，等到需要它直接讀寫本機檔案、跑本機工具鏈時，再回頭安裝 App 或 CLI。Codex 的定位、它與 2021 年那個同名模型的差別、第一個任務怎麼交代，站上已有一篇Codex 入門解析完整談過，這篇專注在安裝與設定這一層。

還有一個名詞先講清楚：安裝教學裡的 Codex，指的是 2025 年回歸、2026 年持續更新的代理式開發工具，不是躲在 GitHub Copilot 背後的那個舊程式碼模型。看到指令裡出現 @openai/codex 這個套件名稱，就是新版的 CLI，兩者已經是完全不同的東西，別混為一談。

安裝前的三個確認

第一個確認是帳號與方案。安裝動作本身不挑方案，免費帳號也能把桌面 App 裝起來，但入口與模型會隨方案拉開：網頁、CLI 與 IDE 擴充功能從 Plus 方案起開通，免費與 Go 方案目前對應的是桌面 App 裡的特定模型。先想清楚你打算用哪個入口，再回頭看自己的方案等級夠不夠，可以省掉「裝好了卻登不進去」的冤枉路。方案細節與計費邏輯在後面費用段落完整整理。

第二個確認是本機環境。Git 是強烈建議的前置：官方安裝文件把 2.23 版以上列為建議值，因為 Codex 內建的合作流程依賴較新的 Git 指令，任務前後的檢查點、把成果開成拉取請求，這些動作底下都是 Git 在做事。記憶體官方儲存庫的安裝文件寫最低 4GB、建議 8GB，以 2026 年的機器標準幾乎不構成門檻，但老機器升級前值得看一眼。磁碟空間沒有官方數字，CLI 本體與對話記錄都是輕量級的，真正佔空間的是它幫你跑的專案與工具鏈。

第三個確認是權限模型的心理建設。Codex 是會動手改檔案、執行指令的代理，安裝完成不等於放任它全權行動。桌面 App 在輸入框下方有核准模式可以選，CLI 端對應的是沙盒與核准參數，例如 --sandbox workspace-write 搭配 --ask-for-approval on-request，讓它預設只能寫工作區、遇到需要擴權的動作先問你。這組參數是官方文件建議的低摩擦起點，先從它開始，用順了再按需求調整。Windows 用戶多一層選擇：原生沙盒或 WSL2 沙盒，後面桌面 App 段落會展開。

桌面 App 路線：Mac 與 Windows 的下載設定

桌面 App 是官方目前主推的圖形介面入口，Mac、Windows、Linux 都有安裝路徑。官方文件給 Mac 與 Windows 的下載位置是 ChatGPT 下載頁，下載安裝後用 ChatGPT 帳號登入，接著在介面裡選擇 Codex 就能開始。App 的一級功能清單，官方 Windows 文件列了工作樹、排程任務、Git 功能、內建瀏覽器、檔案預覽、外掛與技能，等於把 CLI 的核心能力包進一個專案工作區，多個平行的長任務在同一個視窗裡管理。

裝好後的開場流程照官方快速開始走：安裝、登入、選擇工作位置、送出第一個訊息。工作位置可以是新對話、專案或一個資料夾，選資料夾等於讓它讀得到裡面的檔案與上下文。送訊息前先選引擎：要一般對話選 ChatGPT，要動手做事選 Codex，ChatGPT 這側再用輸入框上方的切換選 Chat 或 Work，Codex 這側從新對話開始。這個入口分流是 2026 年版 App 的設計，第一次打開花一分鐘認識它，之後就不會在錯的介面裡問錯的問題。

Windows 這邊有兩個入口。一是官方 Windows App 文件連往 Microsoft Store 的安裝頁，點開即裝；二是文件同時提供的命令列安裝法，在 PowerShell 執行 winget install --id 9PLM9XGG6VKS -s msstore，用 Windows 內建的套件管理器完成同一件事。企業環境的批量部署，官方另有 Intune 與 SCCM 的部署文件，IT 團隊導入時照著走即可。

Windows 原生沙盒與 WSL2：兩種執行模式

Windows 上的 App 有兩種讓代理工作的模式，這是 Windows 使用者最需要搞懂的設定。第一種是原生模式：代理直接在 PowerShell 環境裡跑，受到 Windows 原生沙盒保護。官方沙盒文件說明原生沙盒有兩級，elevated 是偏好的一級，使用專屬的隔離機制；unelevated 是 fallback，兩級都不可用時才考慮別的路線。第二種是 WSL2 模式：代理跑在 Windows Subsystem for Linux 的 Linux 環境裡，吃的是 Linux 沙盒。

怎麼選？官方的建議邏輯很清楚。你的儲存庫與開發流程本來就住在 WSL2 裡、需要 Linux 原生工具鏈，或兩級原生沙盒在你的環境都跑不動，就選 WSL2。反之，一般 Windows 使用者用原生模式即可，不必為了 Codex 特地裝 WSL。切換的方式是在 App 的設定裡把代理從 Windows 原生切到 WSL，然後重新啟動 App。要留意版本門檻：官方 WSL 文件寫明 WSL1 只支援到 Codex 0.114，從 0.115 版起 Linux 沙盒改用 bubblewrap，WSL1 不再支援。還在 WSL1 的環境，先用 wsl --update 把 WSL 元件更新到最新，再用 wsl --list --verbose 確認發行版本別，需要轉換時用 wsl --set-version <發行版名稱> 2 轉到 WSL2；wsl --update 只更新元件本身，不會把發行版從 WSL1 自動升成 WSL2。

在 WSL 模式下工作有個實務細節：檔案路徑。官方文件提醒，把儲存庫放在 Windows 掛載路徑（例如 /mnt/c/...）底下操作會明顯變慢，建議把專案放在 Linux 家目錄（例如 ~/code/my-app），I/O 速度快、符號連結與權限問題也少。Windows 端要存取 WSL 裡的檔案，透過檔案總管輸入 \\wsl$ 就找得到。App 的專案選擇器沒顯示 WSL 儲存庫時，同樣用這個路徑字眼去叫出來。

用指令啟動或安裝：codex app

已經在用 CLI 的人有個快捷方式：終端機執行 codex app，官方 CLI 參考文件說明這個指令會啟動已安裝的 ChatGPT 桌面 App，App 不在時則直接啟動安裝流程。macOS 上可以帶入工作區路徑直接打開專案，Windows 上會印出要開啟的路徑。等於 CLI 與 App 兩條路線之間有一座橋，不必記兩套下載位置。

Linux 桌面用戶不是次等公民：官方為 Ubuntu、Debian、Fedora 與 Arch 都備了安裝指南，照著桌面 App 文件的 Linux 段落走即可。這篇以 Windows 與 Mac 為主軸，Linux 讀者直接看官方指南最準。

CLI 路線：三種安裝法與系統需求

CLI 是安裝彈性最高的入口，官方提供三種安裝法：standalone 安裝腳本、npm 套件、Homebrew。三種都官方支援，差別在前置依賴與更新方式。官方 CLI 文件目前把 standalone 腳本列在第一位，npm 與 Homebrew 是並列的替代路線。

方法一：standalone 安裝腳本（macOS、Linux、Windows）

macOS 與 Linux 的安裝指令是一行：

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Windows 的 PowerShell 版本：

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

這條路的最大優點是零依賴：不必先裝 Node.js，不必裝 Homebrew，指令抓的是編譯好的執行檔。更新用同一個指令重跑一次即可，安裝與更新是同一行。官方 GitHub 儲存庫的說明補充了下載來源的細節：standalone 安裝器預設從 OpenAI 自己的發布網域下載，抓不到時退回 GitHub Releases，也可以強制指定走 GitHub Releases，方法是把環境變數指定給管線後段的 shell：curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_INSTALLER_USE_RELEASES_OPENAI_COM=false sh，變數加在指令最前面是不會生效的，因為那樣只會傳給 curl；Windows 的 PowerShell 則先執行 $env:CODEX_INSTALLER_USE_RELEASES_OPENAI_COM='false' 再跑安裝指令。公司網路擋掉其中一個來源時，這個開關很有用。

方法二：npm

npm install -g @openai/codex

npm 路線適合本來就有 Node.js 環境的人。npm 上的官方套件頁標示的引擎需求是 Node 16 以上，這是官方套件中繼資料寫死的下限，比多數第三方教學轉述的數字寬鬆。更新重跑同一個安裝指令，解除安裝用 npm uninstall -g @openai/codex，就是標準的 npm 全域套件操作。CI 環境想把版本鎖死在特定號次，npm 的版控語意也比腳本路線好用。

要留意權限問題。macOS 的系統 Node 常見全域安裝權限不足的錯誤訊息，解法有二：改用 standalone 腳本路線（它不經過 npm，自然沒有這個問題），或依 Node 社群的建議把 npm 全域目錄移到使用者可寫的位置。安裝卡在權限時，直接換路線通常比 debug npm 環境快。

方法三：Homebrew（macOS）

brew install --cask codex

Mac 上用 Homebrew 管理所有工具的人，把 Codex 比照辦理即可，更新是 brew upgrade --cask codex，解除安裝照 cask 慣例走。注意它是一個 cask（預編譯應用程式），不是從原始碼編譯的 formula，所以升級速度取決於官方發布，不會自己重編。哪天 Homebrew 的版本落後官方最新版，standalone 腳本重跑一次就是最新；兩條路不建議混用，機器上留兩份執行檔時，PATH 順序會決定實際跑到哪一份。

系統需求與三法比較

官方儲存庫的安裝文件列出系統需求：作業系統支援 macOS 12 以上、Ubuntu 20.04 或 Debian 10 以上、Windows 11（表列的支援位置是透過 WSL2）；Git 版本 2.23 以上是選配但官方建議，因為內建的 PR 輔助功能依賴它；記憶體最低 4GB、建議 8GB。這張表是針對從原始碼建置的需求，實際安裝編譯好的執行檔時，Windows 使用者有兩個官方入口可用：前面提過的 PowerShell standalone 安裝指令跑原生版，或者照 WSL 文件在 WSL2 裡裝 Linux 版，兩者都是官方路線，依你的工具鏈選擇。

對終端機還很陌生的人，先別被這節勸退。CLI 的價值在於讓 Codex 直接操作你本機的專案檔案與工具鏈，但你完全可以先用桌面 App 或雲端版上手，需要時再回來裝 CLI。終端機的基本操作邏輯，站上的CLI 命令列入門有完整打底，看完再執行這節的指令會順很多。

IDE 擴充功能路線：把 Codex 裝進編輯器

第三條安裝路線最貼近多數開發者的日常位置：編輯器。官方 IDE 擴充功能文件列出的安裝對象，VS Code 與相容編輯器走擴充功能市集，安裝識別碼是 openai.chatgpt，VS Code 正式版、VS Code Insiders、Cursor、Windsurf 都適用同一個。Xcode 走 Apple 自己的整合，JetBrains 家族（IntelliJ、PyCharm 等）則透過內建的 AI 助手整合，兩者不用從市集裝擴充，直接啟用編輯器既有機制裡的 Codex 選項。

安裝後打開方式：VS Code 系列選側邊的 Codex 圖示，圖示不在時用命令面板執行 Codex: Open Codex Sidebar。Xcode 開 coding assistant 後在新對話裡選 Codex，JetBrains 則在 AI Chat 裡選。登入流程與 CLI 同源，前面提過兩者共享同一份憑證快取，已經在 CLI 登入過的人，擴充功能裡直接是登入狀態。

這條路的獨特價值是上下文就近：你正在看的檔案、選取的程式碼區段，直接拉進提示詞，不必貼路徑或描述檔案位置。改動的審查也在編輯器裡原地發生，摘要與差異並列，留下要的、退掉不要的。官方文件對它的定位是「用你已經在看的程式碼開工」，對照 CLI 的終端機迴圈與桌面 App 的專案工作區，三者的分工由此清楚：編輯器內的小修改用擴充功能，跨檔案的較大任務用 CLI 或 App，背景長任務交雲端。

雲端路線：零安裝的設定流程

第四條路沒有安裝指令，但有設定流程，而且值得寫清楚，因為它是四個入口裡唯一把執行環境放到雲端的。打開 ChatGPT 的 Codex 頁面、用 ChatGPT 帳號登入，這是第一步。第二步是連上程式碼代管平台：官方雲端文件給的是 GitHub 或 GitLab（Beta），GitHub 授權時可以指定哪些儲存庫開放，GitLab 則在建立環境時選專案。第三步是建立環境，在環境設定頁為你的儲存庫配置相依套件、工具、環境變數與密碼，之後同一個儲存庫的任務都在這個可重現的環境裡跑。第四步描述任務、送出，看著任務日誌跑或放著背景執行。第五步審查：摘要加差異，要它改就繼續追問，滿意就在 GitHub 開成 Pull Request、在 GitLab 開成 Merge Request。

雲端版的入口不只網頁。官方文件列出從網頁、GitHub、GitLab、Linear 與 Slack 都能發起任務，等於把 Codex 塞進既有的工作流程裡。與本機的銜接靠 CLI 補上：codex apply <TASK_ID> 把指定雲端任務的最新差異套回本機儲存庫，codex cloud 系列指令直接在終端機管理雲端任務，提交新任務用 codex cloud exec --env <ENV_ID>，列出近期任務用 codex cloud list。本機與雲端並非二擇其一，它們是同一個代理的兩個執行位置。

該不該從雲端開始？兩個判斷點。你的專案已經放在 GitHub 或 GitLab 上，雲端的啟動成本最低，連本機都不用碰。反之，程式碼還沒上雲、或涉及不能離開本機的敏感檔案，就從桌面 App 或 CLI 走。雲端環境的網路存取可以控制，環境的客製化也有專屬文件，這些屬於使用層的設定，安裝階段先記住入口位置就好。

第一次啟動：登入、驗證與第一個任務

安裝完成後，打開終端機，切換到你的專案目錄，輸入 codex。第一次執行時，畫面會問你要用哪種方式登入，預設路徑是 Sign in with ChatGPT：瀏覽器會自動打開 OpenAI 的登入頁，你完成登入後，瀏覽器把憑證交回給 Codex，終端機就完成驗證。不想等第一次啟動的提示，也可以直接執行 codex login，效果相同，這是官方登入文件寫明的預設驗證路徑。

兩種身分：ChatGPT 帳號與 API 金鑰

登入方式有兩種，決定你的計費模型與功能範圍。用 ChatGPT 帳號登入，用量吃你訂閱方案內含的額度，入口與雲端功能依方案開通，而且雲端只能走這條登入路。用 API 金鑰登入，用量走 OpenAI 平台帳號的標準 API 費率，官方文件明講這條路適合 CI/CD 這類程式化工作流程，代價是依賴 ChatGPT 工作區或雲端服務的功能會受限或無法使用，例如 GitHub 自動程式碼審查與 Slack 整合。

API 金鑰的登入指令是把金鑰透過標準輸入餵給 CLI：

printenv OPENAI_API_KEY | codex login --with-api-key

金鑰從 OpenAI 平台的 API 金鑰頁面產生。兩種登入方式都支援，要改用另一種時重跑對應的登入指令即可，用 codex login status 查詢目前生效的驗證方式，用 codex logout 清除目前的憑證。status 指令在憑證存在時以退出碼 0 結束，這個設計對寫自動化腳本檢查登入狀態很好用。

憑證存在哪裡：auth.json 與金鑰圈

登入之後，憑證會快取在本機。預設位置是 ~/.codex/auth.json，或作業系統的憑證存放區，由設定值 cli_auth_credentials_store 決定：file 存檔案、keyring 作業系統金鑰圈、auto 有金鑰圈用金鑰圈、ephemeral 只存在記憶體。預設行為接近 auto。CLI 與 IDE 擴充功能共享同一份快取，在其中一邊登出，另一邊下次啟動也要重新登入。ChatGPT 登入的工作階段會在你使用期間自動刷新權杖，平常不太需要重複登入。

安全提醒要畫底線：檔案形態的 auth.json 內容是明文的存取權杖，官方文件的說法是把它當成密碼對待，不要 commit 進儲存庫、不要貼到工單、不要在對話裡分享。團隊環境可以透過設定強制走 keyring，管理員也能強制限定只能用哪一種登入方式，企業導入時把這條寫進規範。

特殊網路環境：遠端主機與企業代理

兩種環境會讓瀏覽器登入流程卡住，官方文件都給了對策。第一種是遠端或無頭環境（例如 SSH 連上的伺服器），本機回呼拿不到權杖，此時改用裝置碼登入：在登入畫面選 Sign in with Device Code，或直接執行 codex login --device-auth，打開它給的連結、登入、輸入一次性驗證碼就完成。裝置碼功能需要先在帳號的安全設定裡啟用，目前是 beta；官方文件另提供後備做法，在有瀏覽器的機器登入後，把 auth 快取複製到無頭環境。第二種是企業 TLS 代理攔截了連線，設定 CODEX_CA_CERTIFICATE 環境變數指向公司的根憑證 PEM 檔，登入與後續連線就會信任企業憑證鏈。

帳號的歸屬也影響安裝後的體驗。用個人帳號登入，一切照你自己的方案走；隸屬企業或團隊工作區的帳號，登入時選對工作區，因為方案額度、資料保留政策與管理員的控制都跟著工作區走。官方登入文件講得很直白：驗證只是存取的一層，工作區的成員資格與授權才決定你能用哪些表面與功能。公司導入的讀者，安裝前先跟管理員確認工作區有沒有開放 Codex，免得裝完才發現被政策擋住，那不是安裝問題，把指令重跑一百遍也不會解決。

驗收：跑第一個任務與版本確認

登入完成後別急著上工，先做兩個確認。執行 codex --version，記下目前的版本號，之後回報問題、比對功能時都用得到。然後在專案目錄裡給它第一個任務，官方建議的起手句是「Tell me about this project」，讓它讀懂專案結構並回報，這一句同時驗證了檔案讀取、模型連線與輸出整條鏈。送出任務前，官方最佳實務建議在任務前後建立 Git 檢查點，方便事後回退。工作階段中想確認剩餘額度，輸入 /status 就會顯示。

codex doctor：裝完之後的健康檢查

官方 CLI 指令參考裡有一個專門為安裝疑難設計的指令：codex doctor。它會產生一份本機診斷報告，檢查範圍涵蓋安裝狀態、設定檔、登入驗證、執行環境、Git、終端機、app-server 與對話清單的健康狀況，官方對它的定位是回報支援問題前、或調查安裝損壞時先跑的工具。裝完不確定有沒有裝好、升級後行為變怪、登入怪怪的，先跑一次 doctor，多數安裝層的問題會在報告裡直接點名。

登入類的疑難另有專屬記錄檔。每次 codex login 都會在記錄目錄寫一份 codex-login.log，瀏覽器登入或裝置碼流程失敗時，這份檔案是第一現場。更廣泛的記錄位置，官方疑難排解文件列出：macOS 的 App 記錄在 ~/Library/Logs/com.openai.codex 依日期分層的目錄，對話逐字稿在 ~/.codex/sessions，封存的對話在 ~/.codex/archived_sessions。要把記錄貼給別人看之前，先自己讀一遍，確認裡面沒有敏感內容。

另一個常見困惑也記在官方文件裡：某個功能在 CLI 有、在桌面 App 沒有，或反過來。原因是桌面 App 與 CLI 各自帶著不同版本的 Codex 核心，實驗性功能通常先到 CLI。Mac 上想確認 App 綁的版本，用這個路徑執行：/Applications/Codex.app/Contents/Resources/codex --version，與 codex --version 的輸出比對就知道兩者差幾版。

版本與更新節奏：安裝之後的維運觀念

Codex 的版本號走得很快，本篇撰寫當下，npm 上的官方套件最新版是 0.157.1，這個數字放幾週就過時，寫在這裡純粹當時間戳。比較有參考價值的是維運觀念。第一，更新管道跟安裝管道是同一條：standalone 腳本重跑、npm 指令重跑、Homebrew upgrade，桌面 App 則跟著作業系統與 App 自己的更新機制走，Windows 經 Microsoft Store 安裝的版本由商店推送更新，企業環境另有官方的更新管理文件，讓 IT 控制何時讓組織升級。把「怎麼裝」跟「怎麼更新」綁在一起記，安裝時就知道自己簽下了什麼樣的維護節奏。

第二，文件本身也在每週演化，官方維護一份每週更新摘要，功能、鍵位與方案範圍都會移動，教學文章（包括這一篇）都是快門下的照片，官方文件才是實況。養成習慣：指令行為跟教學不一致時，先查官方指令參考，再查每週摘要，多半能找到「上週改了什麼」的答案，省下自己試錯的時間。

第三個觀念是跨表面版本差的存在。CLI、桌面 App、IDE 擴充功能各自更新，功能落地的時間點自然不同，文件裡的某個指令在你的版本沒有，先確認版本，再往下找其他原因。團隊要統一版本的話，npm 路線可以鎖特定版號，官方儲存庫還提供 DotSlash 檔案的發布形式，讓同一份執行檔規格被 commit 進儲存庫，所有貢獻者拿到一致的可執行版本，這是 open source 專案統一開發環境的官方解法，一般個人用戶用不到，知道有這個東西即可。

降級與版本控制是另一個極端需求。絕大多數人永遠用最新版就好，官方修復與新功能都在最新端；唯二需要回頭看的情境，是新版與你的工作流程出現明確衝突，或 CI 裡的腳本依賴特定行為。前者等修復或暫用 App 替代，後者用 npm 鎖版，兩者都不建議長期停在舊版，安全修正會跟不上。

常見安裝問題排解

與安裝有關的挫折，九成落在幾個固定模式，對照下表可以先做第一輪分類：

逐項展開講。指令打完卻說 command not found，代表安裝完成的執行檔不在 PATH 裡，用 command -v codex（Windows 原生環境用 where.exe codex 或 Get-Command codex）確認執行檔位置，通常重開終端機讓 PATH 生效就解決；WSL 環境裡找不到指令，多半是裝在 Windows 端而 Linux 端沒裝，進 WSL shell 重跑一次 Linux 安裝腳本即可，官方 WSL 文件的排解段給的就是這個順序。

npm 安裝報權限錯誤，前面提過對策：換 standalone 腳本是最快解法，它不依賴 npm 的全域目錄權限。升級後 CLI 與 App 行為不一致，先比對兩邊版本號，再跑一次 doctor 看安裝狀態。瀏覽器登入視窗跳出來卻一直轉，檢查是不是企業代理環境，套上 CA 憑證環境變數；遠端主機上直接改用裝置碼登入。WSL 裡跑大儲存庫覺得慢，把專案從 /mnt/c 搬到 Linux 家目錄，官方文件明白警告跨檔案系統的 I/O 會拖慢速度，這個搬家動作的效益通常立竿見影；搬完之後若 WSL 本身反應慢，用 wsl --update 與 wsl --shutdown 重啟子系統，是官方文件給的標準組合。

這些模式的共同點是：先確認版本與路徑，再跑 doctor，重灌是最後手段。安裝損壞的重灌其實很少真的需要，doctor 的報告通常會指出具體是哪一層壞了。真的要回報問題，GitHub 儲存庫的 issue 頁是官方指定的渠道，貼上 doctor 報告與版本號，處理速度會快很多。

方案門檻與費用：誰裝得起、怎麼計費

安裝免費，用量計費才是重點。官方方案頁在 2026 年 9 月的結構是：免費方案可以在桌面 App 用 GPT-6 Luna（標準速度，分批推出中）；每個月 8 美元的 Go 方案同樣是桌面 App 的 Luna；每個月 20 美元的 Plus 方案是分水嶺，從它起開通網頁版、CLI、IDE 擴充功能與 iOS，模型有 GPT-6 Sol 與 GPT-6 Luna，超出內含量可以用加購點數延長；Pro 方案從每個月 100 美元起，提供 Plus 的五倍或二十倍用量。API 金鑰路線不在這張階梯上，它按 API 費率逐筆計費，模型可用性跟著你金鑰能用的模型走。企業側的 Business 方案是每席每月 20 美元起（年繳、兩席以上，月繳單價 25 美元）。

幾個計費原則比數字更重要。本機訊息與雲端對話共享同一份方案用量，五小時為一個滾動區間，實際可用訊息數隨任務大小、模型選擇、上下文長短浮動，官方明言數字是估計而非固定上限。打到上限時不需要硬等重置：Plus 與 Pro 用戶可以加購點數繼續工作，有 OpenAI 平台帳號與計費設定的用戶，也能改用 API 金鑰跑額外的本機對話，按標準 API 費率計費，兩條延長線讓工作不中斷。查詢即時用量有兩個入口：CLI 工作階段裡的 /status，以及 ChatGPT 網站上的用量儀表板，官方建議每一兩週看一次，掌握自己的消耗節奏。額度與方案的完整互動關係，可以對照站上的ChatGPT 與 Claude 額度算法一起理解，跨工具的用量管理邏輯是相通的；Codex 的即時額度仍以官方方案頁與用量儀表板為準。

點數與權杖的關係也值得一提，因為它影響你怎麼解讀帳單。官方文件的定義是：權杖是模型讀寫資訊的最小單位，你的提示、檔案、對話歷史、工具輸出與回應都在消耗它；點數則是加購與企業彈性計費的單位，超過內含量之後接著扣。同一個任務的消耗量會因為快取命中、推理深度、影像生成等條件差好幾倍，所以官方的建議別放在記數字上，重點是看儀表板建立自己的直覺，發現消耗異常時，優先檢查任務範圍是不是開太大、模型是不是選太重。

台灣使用者可以直接照官方流程付費，方案價格以官方頁面即時顯示為準，功能推出的地區與時程（例如免費方案的 Luna 分批開放）依帳號狀態而有先後，看不到某個入口時，先確認方案等級與版本，先別急著懷疑安裝壞了。

解除安裝與乾淨移除

官方安裝文件目前沒有提供統一的解除安裝指令，但依安裝路線反向操作都很直接。npm 裝的用 npm uninstall -g @openai/codex；Homebrew 裝的照 cask 慣例解除；standalone 腳本裝的，刪掉執行檔本身即可，用 command -v codex 找到位置再處理，若執行檔跟其他程式放在同一個目錄，不要連整個目錄一起刪。桌面 App 的移除跟著作業系統的標準流程走，macOS 拖到垃圾桶、Windows 從設定裡的應用程式清單移除。

真正的「乾淨」還包括使用者資料目錄。~/.codex 底下住著設定檔、AGENTS.md 相關設定、對話逐字稿與登入憑證，移除程式本體不會動它。要徹底清掉，先執行 codex logout 再把資料目錄刪掉；憑證若存在金鑰圈，單刪目錄清不到它；只想清掉登入身分，執行 codex logout 就夠。反過來說，換電腦時這個目錄裡的設定與對話就是你要搬的東西，登入憑證建議在新機重新登入取得，不要把舊機的存取權杖原封搬過去，設定與對話的完整磁碟地圖，站上的Codex 進階操作解析有一節專門講備份管理，搬家前值得先讀。

重灌與升級的關係也順便說明。重跑安裝指令就是覆蓋安裝，設定與對話不受影響，所以「升級後怪怪的」照同一套順序：先確認版本與路徑，再跑 doctor，報告指向安裝損壞才重跑安裝指令。真的判斷是設定檔壞了，把 ~/.codex 裡的設定檔暫時移開再啟動，用乾淨狀態排除法驗證，這個動作可逆，比刪整個目錄溫和。把「移除程式、保留資料、重灌程式」這三步的順序記住，安裝層的問題幾乎都有出路。

怎麼選：一套安裝決策與下一步

把整篇收斂成決策表，對著自己的工作習慣對號入座（IDE 與雲端版是否可用，記得回頭對照前面談過的方案門檻）：

幾個合併使用的常見組合也提一下。開發者的典型配置是 CLI 加 IDE 擴充功能，兩者共享登入，終端機跑大任務、編輯器裡做小修改。行銷與內容工作者的輕量配置是桌面 App 加雲端版，App 裡管理專案檔案，雲端丟背景任務。團隊導入通常是企業方案加管理文件：工作區開通、管理員設好登入限制與更新策略，成員各自安裝表面。路線之間不互斥，用 ChatGPT 帳號登入時，登入身分與方案用量跨入口共通（API 金鑰路線另走平台計費），先裝一個跑通，之後按需求疊加。

想把長任務丟到背景平行跑、又還沒有版本控制習慣的人，裝雲端版之前想入門版控概念，可以先看GitHub Repo 的非工程師入門，理解儲存庫與拉取請求的語言，雲端版的審查流程才看得順。

裝完之後的路線圖也簡單：先用官方建議的起手句驗證整條鏈路，跑一次 doctor 留下健康基準，把 codex --version 的輸出記下來。接下來的使用深度，交辦任務的描述技巧、任務中途轉向、手機接手、對話整理與備份，站上從入門到進階都有專文接手。安裝這一步的本質是把工具放到你的機器上，真正決定產值的是之後怎麼把任務講清楚、怎麼審查它的產出，這條學習曲線的投資報酬率，比安裝本身值得花的心力高得多。

回到安裝決策的本質：入口沒有優劣，只有匹配。同樣一個 Codex，在設計師的 Mac 上是桌面 App 裡的專案工作區，在後端工程師的終端機裡是一行 codex，在資料團隊的瀏覽器裡是雲端任務佇列。先誠實評估自己每天工作的位置，再挑入口，安裝的十幾分鐘只是開始，讓工具長期留在你的工作流裡的，是那個一開始就選對的位置。