OpenAI Codex 怎麼用？雲端版與 Codex CLI 從登入到權限一次看懂

Codex 比較像一位能同時坐在你電腦旁邊、也能被派到遠端機房上班的工程師助理，而不是一個等你發問才回話的聊天視窗。它會讀專案、改檔案、跑指令，而且交給雲端的那一份工作，在你闔上筆電之後還會繼續做下去。

麻煩的是，同一個名字底下其實分成好幾個入口，終端機裡有 Codex CLI，編輯器裡有延伸套件，另外還有桌面 App 和網頁上的雲端版。再加上不少舊教學還在介紹已經改掉的權限模式，照著做常常第一步就對不上畫面。

這幾個入口共用同一個 ChatGPT 帳號與用量額度，差別主要在「程式碼放在哪、指令在哪台機器上跑」。弄清楚這一點，後面的登入方式、安裝步驟和權限設定才有判斷的依據。

Codex 是什麼？

Codex 是 OpenAI 推出的程式開發代理（coding agent）。OpenAI 說明中心把它概括為「協助你撰寫、審查並交付程式碼的 AI 代理」。實際運作時，它會先讀懂你的專案，再依你交代的任務修改檔案、執行指令、跑測試，最後把結果交回來讓你檢查。

和單純回答程式問題的聊天視窗相比，差別在於 Codex 直接對專案本身動手。你描述一個目標，它自己決定要看哪些檔案、改哪幾行、跑哪些指令驗證，你再審查它交出的差異內容（diff）。

目前同一個帳號可以從四個地方使用：終端機的 Codex CLI、編輯器裡的 IDE 延伸套件、支援 macOS、Windows 與 Linux 的桌面 App，以及能在網頁、手機和桌面 App 之間接續的雲端版。

Codex 用的就是你的 ChatGPT 帳號與方案，在桌面 App 裡則是一個獨立的檢視，對話紀錄和 ChatGPT 的歷史分開保存。容易混淆的是 ChatGPT 裡另一個叫 ChatGPT Work 的體驗，它負責較長的研究任務，以及文件、簡報這類交付物，和專心處理軟體開發的 Codex 是兩個不同的東西，只是兩者共用同一套用量額度。

另一個常被問到的是開不開源。Codex CLI 的原始碼公開在 GitHub 的 openai/codex 專案，採 Apache-2.0 授權，主要以 Rust 寫成。所以你搜尋 codex cli 時看到的 GitHub 頁面，就是這個終端機版本的本體，而不是第三方包裝出來的東西。

本機執行和雲端執行是 Codex 各入口最大的分野

選哪個入口，其實只取決於三件事：程式碼放在哪裡、指令在哪一台機器上跑、電腦關機之後任務還能不能繼續。這三件事一旦確定，剩下的功能差異都是細節。

OpenAI 把這兩種用法分成 Codex Local 與 Codex Cloud。Codex Local 涵蓋 CLI、IDE 延伸套件和桌面 App 的本機工作，Codex Cloud 則是交給雲端執行的委派任務。在企業工作區裡，管理員可以分別開關這兩邊，所以兩者是並行存在的選項，而不是誰取代誰。

Codex CLI 直接在你的電腦上動手

Codex CLI 在你指定的專案資料夾裡啟動，直接讀本機檔案、改檔，並使用你電腦上已經裝好的工具跑指令。OpenAI 對它的定位有三句：針對本機倉庫工作、由你掌控模型與權限、能放進腳本和 CI 流程。

第二句的意思是，模型、推理強度、權限和可用指令都由你自己挑，不必接受預設值。第三句則是說同一個 codex cli 既能互動使用，也能用 codex exec 放進可重複執行的流程。啟動畫面會顯示目前的模型與目錄；最常用的起手指令有 /init、/status、/permissions、/model、/review 這五個。

雲端版在 OpenAI 管理的虛擬機執行，闔上筆電也不會中斷

雲端版的任務跑在 OpenAI 管理的電腦上，使用可重複利用的雲端環境。因為工作不依賴你的電腦，所以任務在你闔上筆電後仍會繼續，回來時再審查結果即可。

要開雲端任務，可以在 ChatGPT 網頁或桌面 App 的新任務裡，從 Work in 選單選 Cloud，在行動裝置上則直接打開 Codex。手機上可以選已經發佈的環境開始任務，但建立環境本身要在網頁或桌面 App 進行。

桌面 App 與 IDE 延伸套件的開啟方式和共用設定

在桌面 App 裡選 Codex 就能進入，也可以在終端機輸入 codex app 開啟。IDE 延伸套件支援 VS Code、Cursor 與 Windsurf，在側邊欄點 Codex 圖示就能開始；Xcode 和 JetBrains 則是各自的整合，分別在編碼助理與 AI Chat 裡選 Codex。

這三個本機入口共用同一份 MCP 設定，設定一次就能在 App、CLI 與 IDE 之間換著用。如果你的 IDE 沒有對應的延伸套件，也可以直接在內建終端機裡執行 Codex CLI。

登入帳號決定可用功能與計費方式

最常見的疑問是「要不要付費、要不要另外申請 API 金鑰」，答案取決於你用哪一種方式登入。Codex 支援用 ChatGPT 帳號登入，也支援用 API 金鑰登入，而這兩條路的計費邏輯完全不同。

Codex 包含在各個 ChatGPT 方案裡，連 Free 與 Go 也能用，只是用量依方案而異。依 OpenAI 定價頁的說明，這兩個方案是在桌面 App 裡使用 Codex，並依推出進度陸續開放，不含雲端版。雲端版的門檻較高，只開放給符合資格的 Plus、各級 Pro、Business、Enterprise、Healthcare 與 Education 帳號，實際能不能用，還要看推出進度與工作區設定。各方案的價格會調整，請直接看 OpenAI 的定價頁。

ChatGPT 帳號登入，沿用方案內含額度

這是 OpenAI 建議的預設路徑。在終端機執行 codex 後選 Sign in with ChatGPT，或直接執行 codex login，瀏覽器完成登入後，憑證會回傳給 Codex。以這種方式登入時，消耗的是你方案內含的額度，不會另外計費。

登入之後，codex login status 能查目前用的是哪一種登入方式，codex logout 則會清掉已儲存的憑證。桌面 App 和 IDE 延伸套件也有各自的登入按鈕，登入流程相同。OpenAI 說明中心還提到，桌面 App 可能要求你加入或驗證電話號碼，遇到這個提示不必意外。

API 金鑰登入，依用量另計費

金鑰路徑適合腳本與 CI。在 Mac 或 Linux 的終端機，可以用標準輸入把金鑰送進去，避免金鑰直接留在指令列的歷史紀錄裡：

printenv OPENAI_API_KEY | codex login --with-api-keyCode language: Bash (bash)

用金鑰登入時，Codex 改按標準 API 費率計費，不會動用 ChatGPT 方案內含的額度。代價是依賴 ChatGPT 工作區或雲端服務的功能會受限，雲端版則完全用不了。OpenAI 也提醒，金鑰登入適合 CI/CD 這類程式化流程，不要把 Codex 暴露在不受信任或公開的環境裡。

Codex CLI 的安裝與第一次啟動

codex cli 的上手路線很單純，選一種安裝管道、第一次啟動時登入，再進到專案資料夾先讓它讀懂專案。步驟本身不難，比較需要想清楚的是每一步背後的安排，例如第一個任務為什麼不該急著改檔。

安裝管道共有三種：獨立安裝器、npm 與 Homebrew。Windows 用 PowerShell 一行指令安裝，Mac 與 Linux 則用 shell 一行指令。指令可能隨版本調整，實際以 GitHub 專案頁當下的內容為準。

Mac、Linux 與 Windows 的安裝指令

Mac 與 Linux 的獨立安裝器：

curl -fsSL https://chatgpt.com/codex/install.sh | shCode language: Bash (bash)

Windows 的 PowerShell 安裝器：

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"Code language: plaintext (plaintext)

獨立安裝器預設從 OpenAI 的發佈站下載，如果中繼資料或檔案暫時取不到，就會退回 GitHub Releases。更新時重新執行同一條安裝指令即可。

習慣用套件管理員的話，也可以改用 npm 或 Homebrew，後者要記得加上 --cask：

npm install -g @openai/codex
brew install --cask codexCode language: Bash (bash)

另外還有一條手動路線，就是到 GitHub Releases 下載對應平台與架構的壓縮檔，解壓後把檔名改成 codex。

在 Linux 和 Windows 的 WSL2 上，沙盒需要 bubblewrap，缺少時 Codex 啟動會顯示警告，先裝好就能避開：

sudo apt install bubblewrapCode language: Bash (bash)

Windows 的桌面 App 預設用原生 PowerShell 搭配 Windows 沙盒，也可以切換到 WSL2。較早期的 WSL1 在沙盒機制改用 bubblewrap 之後已經不再支援，要用 WSL 的話請選 WSL2。

登入後先讓 Codex 讀懂專案

第一次啟動建議照這個順序，在專案資料夾執行 codex、完成登入，然後先問一個不會改動任何檔案的問題。OpenAI 的範例是「Tell me about this project」，請它說明這個專案在做什麼。

這樣安排的理由是先確認 Codex 看得到的範圍，和你預期的是否一致。如果它對專案的理解有偏差，趁還沒動任何檔案時發現，成本最低。接著可以用 /init 產生 AGENTS.md，把專案規則寫下來；/status 則會顯示目前的模型、核准政策、可寫入的目錄與用量。

OpenAI 也建議在任務開始前和結束後各建立一個 Git checkpoint（也就是一次 commit）。這樣不論 Codex 改得對不對，你都能隨時回到動手之前的狀態。

Codex CLI 日常會用到的內建功能

日常操作 Codex CLI 時，常用到的功能包括控制指令、專案規則、接續舊對話、補充上下文、分工並行、連接外部工具、審查與自動化，完整旗標可查 OpenAI 的 CLI 說明文件。

其中 codex exec 與 codex review 這兩個指令，是 codex cli 從互動對話走向自動化流程的橋梁。

斜線指令控制整段工作階段

互動介面裡以 / 開頭的指令，能即時調整行為。/init 建立 AGENTS.md，/status 查看目前的設定與剩餘額度，/permissions 選擇 Codex 能自己做哪些事，/model 切換模型與推理強度，/review 則針對目前的變更跑一輪審查。

模型更新得很快，需要時用 /model 看目前有哪些選項即可。推理強度調高通常能改善複雜任務的結果，代價是花更久的時間、用更多 token。另外，工作進行中你還能補充指示，按 Enter 會把訊息加進目前這一輪（steer），按 Tab 則排進下一輪（queue）。

AGENTS.md 固定專案的工作規則

AGENTS.md 是 Codex 動手前會先讀的指示檔。把「這個專案怎麼測試、哪些地方不能動」寫進去一次，之後每個任務都會照著走，不必每次重新交代。

它有兩層來源。全域的放在 ~/.codex/AGENTS.md，若同一個資料夾有 AGENTS.override.md 就優先採用；專案的則從專案根目錄往下，一路讀到目前所在的資料夾，每個資料夾最多收一個檔案。合併時由根目錄往下串接，離目前資料夾越近的越晚出現，優先權也越高。

預設的總大小上限是 32 KiB（設定鍵為 project_doc_max_bytes），累積到上限就停止讀入，所以不要把整份操作手冊塞進去。你也可以用 project_doc_fallback_filenames 設定備用檔名，例如 TEAM_GUIDE.md。一份實用的規則可以很簡短：

改完 JavaScript 檔案後，一律先執行 npm test。
資料庫遷移檔案不要直接修改，需要變動時另開新的遷移檔。Code language: plaintext (plaintext)

codex resume 接回先前的對話

codex resume 會重新打開目前專案最近的一段對話，不必重新交代背景。當天的工作被打斷、隔天要接著做時，這是最省事的做法。

如果要找的是更早以前的工作，加上 --all 可以跨資料夾搜尋，--last 則會跳過選單直接接回最近一次。這兩個旗標讓你不必記住對話編號。

在提示附上圖片與開啟即時網路搜尋

遇到畫面上的問題，用 --image 在第一個提示附上錯誤截圖、架構圖或設計稿，Codex 就能對照圖片和程式碼一起判斷；在互動輸入框裡直接貼圖也可以。

網路搜尋預設走快取，也就是用事先整理好的結果。需要最新的文件或剛發佈的資訊時，加上 --search 切到即時搜尋，搜尋的過程會留在對話紀錄裡，方便事後檢查它查了什麼。

子代理和 worktree 讓工作分頭並行

子代理是 Codex 為了獨立的子任務額外啟動的專門代理。大任務可以拆成幾條互不干擾的工作，各自處理後再把摘要結果帶回主對話，雜亂的記錄與測試輸出就不會塞滿主對話。目前的版本預設啟用這項功能。

代價是額度消耗，每個子代理都有自己的模型與工具用量，加總起來會比單一代理高。至於 Git worktree，它讓同一個專案裡的不同任務各用一份獨立的工作副本，彼此不會互相覆蓋。各副本共用同一份 .git 中繼資料，所以 worktree 只能用在 Git 專案。

MCP、skills 與外掛的擴充方式

這三項都是擴充，不是必要設定。MCP（Model Context Protocol）讓 Codex 連到第三方文件與開發工具；skills 把重複的工作流程寫成可重用的指示；外掛則把 skills 與連接器打包起來分享。沒有這些需求就先不用管它們。

MCP 的設定預設存在 ~/.codex/config.toml，也可以用專案層級的 .codex/config.toml，但只對信任的專案生效。它支援 STDIO 與可串流 HTTP 兩種伺服器，指令是 codex mcp，例如用 codex mcp add 新增一個伺服器。每多接一個 MCP 伺服器，就多佔用一份上下文與額度，暫時用不到的先關掉。

skills 是一個含有 SKILL.md 的資料夾，Codex 平常只看各 skill 的名稱和描述，真的要用時才載入完整內容，所以裝很多也不會一開始就吃掉大量上下文。

codex review 先審本機變更

在送出 commit 或開 pull request 之前，可以讓 Codex 單獨跑一輪審查。它只會回報依優先順序排列的發現，不會改動你的工作目錄，可以放心當作最後一道檢查。

審查的對象有三種：未提交的變更、單一 commit，或與某個基準分支的差異。三個旗標以及自訂提示彼此互斥，一次只能選一個：

codex review --uncommitted
codex review --base main
codex review --commit <SHA>Code language: Bash (bash)

codex exec 放進腳本與自動化流程

codex exec 不開互動介面，適合 CI、定時工作，或把輸出接給其他指令。進度訊息走 stderr，最終答案走 stdout，所以把結果導向檔案時不會混進過程記錄。加上 --json 還能輸出事件流，讓程式逐行讀取。

預設的 codex exec 在唯讀沙盒裡執行，要允許改檔得明確指定：

codex exec --sandbox workspace-write "<任務描述>"Code language: Bash (bash)

舊腳本常見的 --full-auto 已被標為舊相容旗標，新腳本請改用明確的 sandbox 旗標。danger-full-access 則只該用在隔離的 CI 執行器或容器裡。想在 GitHub 上跑，另有 Codex GitHub Action（openai/codex-action@v1），也有 SDK 可以用程式呼叫。

沙盒與核准機制限制了 Codex 能動到的範圍

讓一個會改檔、會跑指令的代理在自己的電腦上工作，最需要先弄清楚的是「它最壞能做到哪」。Codex 用兩層彼此獨立的控制回答這個問題，沙盒管它能做什麼，核准則管它動手之前要不要先問你。

預設值偏保守。OpenAI 的說明是，代理預設在網路關閉的狀態下執行，本機使用作業系統層級的沙盒，再搭配一套核准政策，決定哪些動作必須先停下來等你同意。

沙盒預設不連網，只寫入工作目錄

在 CLI 和 IDE 延伸套件裡，沙盒是由作業系統層級的機制強制執行的。預設沒有網路，寫入權限也只限於目前的工作區。各平台用的機制不同，macOS 用內建的 Seatbelt，Windows 在 PowerShell 下用原生 Windows 沙盒，Linux 與 WSL2 則用 bubblewrap。

這個沙盒不只管 Codex 自己的檔案操作，也套用在它衍生出來的指令上。git、套件管理員、測試執行器都繼承同樣的邊界。至於雲端版，每個任務跑在 OpenAI 管理、各自隔離的虛擬機裡，和你的電腦沒有直接關係。

權限分成唯讀、Auto 與完整存取，舊模式名稱已不適用

現行的設定可以理解成三個層級。唯讀適合只想聊天或規劃、不希望任何檔案被動到的時候。Auto 是預設的組合，等於 workspace-write 搭配 on-request，Codex 可以在工作目錄內自動讀檔、改檔、跑指令，只有碰到要編輯工作區之外的檔案，或需要網路的指令時，才會停下來問你。

完整存取（danger-full-access）則等於拿掉邊界。OpenAI 明確警告，在這種模式下 Codex 不再受限於你的專案目錄，可能做出非預期的破壞性動作，造成資料遺失。切換權限可以在互動介面輸入 /permissions，或在啟動時指定 --sandbox 與 --ask-for-approval 旗標。

照舊教學操作，最容易踩到的是模式名稱對不上。舊教學常見的 Suggest、Auto Edit、Full Auto 三種模式名稱，在目前的說明文件裡已經沒有對應，現行的是上面的唯讀、Auto 與完整存取。同樣不再適用的還有 approval_policy = "untrusted"，OpenAI 已停止支援這個核准政策，設定檔裡留著它，Codex 可能直接無法啟動。替代的做法是改成唯讀沙盒搭配按需核准：

sandbox_mode = "read-only"
approval_policy = "on-request"Code language: plaintext (plaintext)

另外還有一項 Auto-review，開啟後，原本要停下來等你核准的動作，會先交給另一個審查者檢查。用 ChatGPT 帳號登入時，這類檢查免費，不計入額度。不過它不會取代工作區的限制，只是減少你被一再打斷的次數。

程式碼與對話的資料處理依登入方式而定

資料怎麼被使用，要看你用什麼方式登入。用 ChatGPT 帳號登入時，資料政策跟著帳號類型走；用 API 金鑰時，則跟著 API 組織的保留與分享設定走。

依 OpenAI 說明中心的說法，Business、Enterprise 與 Edu 方案預設不會拿輸入與輸出內容訓練模型。Plus 和 Pro 的對話則可能被用來改進模型，除非你在 ChatGPT 的資料控制裡把訓練關掉，使用個人方案的話，建議自己確認這項設定。至於資料落在哪裡，雲端任務跑在 OpenAI 管理的環境中，本機工作的專案檔案則留在你的電腦上。

Codex 雲端版從建立環境到收回成果

雲端版比 CLI 多了一道前置工作，得先建立一個環境，任務才有地方跑。依 OpenAI 的說明文件，完整流程大致是選 GitHub 倉庫、由 Codex 檢查並測試、發佈環境、開任務、審查結果，最後 commit 或開 pull request。使用前提是符合資格的方案，企業工作區還得由管理員開啟雲端權限。

環境發佈後才能開始任務

環境是任務共用、可重複使用的設定，包含倉庫、相依套件、工具與存取權。好處是你不必從頭寫安裝腳本，Codex 會從倉庫判斷需要的執行環境、套件版本、工具與服務，並在對話中跟你一起調整設定。

建立流程從網頁或桌面 App 的新任務開始，選 Work in 裡的 Cloud，打開 Select environment 後選 Create environment，再選要檢出的 GitHub 倉庫（必要時先連接 GitHub）並按 Get started。接著 Codex 會檢查倉庫、安裝相依套件與工具，並測試整個流程；缺少存取權或資訊時會向你索取。確認設定報告後儲存並按 Publish，出現 Environment published 才算完成，這時就能 Start a new task。

環境的設定記錄在兩個欄位裡，Install script 放安裝相依套件的指令，Start skill 則寫明怎麼啟動服務並檢查是否就緒。修改已發佈的環境要先按 Edit，改完再按 Republish，新任務才會套用新設定，舊任務保留自己原本的狀態。環境也可以設為只有自己能用，或開放整個企業工作區使用。

每個任務各有獨立的虛擬機與工作空間

每個雲端任務都在自己的虛擬機裡執行，規格依方案而定。目前 Plus 與 Edu Plus 的預設規格是 2 vCPU、8 GiB 記憶體、8 GiB 磁碟；Pro、Business、Enterprise、Edu 與 Edu Pro 則是 4 vCPU、16 GiB 記憶體、32 GiB 磁碟。

任務的虛擬機狀態，在你最後一次操作之後預設最多可以復原 7 天。重新打開同一個任務，就能在網頁、行動裝置與桌面 App 之間接續工作；新任務則會從已發佈的環境重新開始。OpenAI 特別提醒，儲存的狀態不能取代版本控制，重要的成果一定要 commit。任務結束後，結果會交回給你審查，滿意再 commit 或開 pull request。

網路存取與機密資料要在環境裡設定

雲端虛擬機能連到哪些網域，由環境的網路設定決定。需要裝私有套件或呼叫外部 API 時，你得自己決定放行哪些網域，並選擇用什麼方式傳遞金鑰。

網路部分先打開 Allow Codex to access internet，再在 Allow domains 選 Package managers 或 Custom domains only（可補充額外網域），要完全不設限則選 All（unrestricted）。放行網域不等於給憑證，認證仍要你自己處理。

傳遞金鑰有兩種方式，用途不同。環境變數是程式必須直接讀取的值；網路機密則是只對指定 HTTPS 服務送出的憑證，程式本身只拿到佔位符，真正的值由代理伺服器在允許的目的地替換上去，而且只支援 443 埠的 HTTPS。共用環境時，個人金庫（Personal vault）讓每個人各自提供自己的值，不必共用同一份憑證。需要連到內部網路的服務時，可以在環境的進階設定加上 VPN 連線，目前支援的 VPN 供應商是 Tailscale。

從 CLI 送出雲端任務再套用回本機

這是雲端版與 CLI 兩條線交會的地方。codex cloud 能瀏覽進行中與已完成的雲端對話，把工作送到設定好的環境，再把結果套用回本機倉庫。直接執行 codex cloud 會開啟互動選單，codex cloud exec 可以直接送出任務，codex cloud list 則列出近期對話，適合給腳本使用。

結果要回到本機時，用 codex apply 加上任務 ID，把該雲端對話最新的 diff 套用到本機倉庫。套用時如果 git apply 遇到衝突，指令會列出衝突並以非零的結束碼退出，處理完衝突再重試即可。

codex cloud exec --env <環境 ID> "<任務描述>"
codex apply <TASK_ID>Code language: Bash (bash)

GitHub 上的 @codex review 不用建環境

Codex 也能直接審查 GitHub 的 pull request，而且不需要你自己建立或管理雲端環境。做法是在 PR 留言輸入 @codex review，Codex 會先加上眼睛表情的反應，然後貼出審查結果。也可以在 Codex 設定裡打開 Automatic review，讓每個 PR 都自動審一次。

前置條件是把 GitHub 倉庫連到 Codex，並擁有該倉庫設定的 push 或 admin 權限。GitHub 上只會標出 P0、P1 這類高優先的問題。想讓審查聚焦在特定範圍，可以把重點直接寫在留言裡，例如 @codex review for issues in the database migration。

審查規則可以寫進倉庫裡最接近程式碼的 AGENTS.md，用一個 ## Code Review Rules 段落調整。建議先寫兩三條精簡的規則，格式化、lint 這類機械檢查留給 CI 處理。要記得規則只是引導，不取代測試、分支保護與必要的核准。另外，GitHub 上的審查用量另計，在本機或 GitHub 之外執行的審查則算一般用量。

雲端版尚未支援的項目與舊版的停用計畫

雲端版目前有幾項限制，先看清楚比較不會在建好環境之後才發現不能用。電腦與瀏覽器操作尚未支援，GitLab 與自架的 GitHub Enterprise Server 也還在規劃中。放在倉庫裡的 skills 可以在雲端任務使用，但本機個人的 skills 不會同步上去。

此外還有一個過渡期的狀況。舊版的「Codex Cloud」（Legacy）仍支援 Code Review 與 Linear、GitHub 整合，但 OpenAI 表示計畫停用這個舊體驗，尚未公布日期。網頁、行動裝置與桌面 App 上的雲端任務走的則是新版環境。這些都屬於路線圖性質的資訊，會隨版本變動，請以 OpenAI 的說明頁為準。

額度的計算方式與查看位置

決定要不要長期使用時，多數人最關心的是「用到什麼時候會被擋下」。價格與各模型的可用訊息數都會變動，實際數字以 OpenAI 的方案說明為準。

本機訊息與雲端對話共用同一份方案額度，另外還可能有每週的限制。

影響額度消耗的因素

看起來相似的任務，實際用量可能落差很大。模型選擇、上下文大小、推理強度、工具使用、檢索與快取都會影響，所以光看提示詞長短來估算並不可靠。任務本身的大小與複雜度、在本機還是雲端執行，同樣會改變消耗。

有幾個設定特別耗額度。Fast 與 Ultrafast 模式會以更高的倍率消耗額度；子代理、MCP 伺服器和過長的 AGENTS.md 也會增加每次的上下文量。現行規則下，Plus 與標準 Business 以每 5 小時為單位估算用量，Pro 則沒有這項 5 小時限制。

想讓額度撐久一點，有幾個做法：提示詞只寫必要的細節、只提供相關的檔案、把 AGENTS.md 縮短，以及少開 MCP 伺服器。額度用到上限時，進行中的那一輪還可以繼續做完（受公平使用限制），之後可以購買額外額度（Plus 與 Pro 可直接加購，採彈性計價的 Business、Edu、Enterprise 則可加購工作區額度）、等額度重置，或升級方案，但客服不會代為重置額度。OpenAI 說明中心也提到，標準雲端環境推出時沒有另外收取虛擬機費用，用量仍照模型消耗計算。

在 CLI 與設定頁查看剩餘額度

在 CLI 的工作階段裡輸入 /status 就能看到剩餘額度，不必離開終端機；長任務開工前先看一眼，能確認額度夠不夠用。

桌面 App 與網頁版則到 Settings 或使用量儀表板，查看目前的限制與重置時間。

適合交給 Codex 的任務、入口選擇與需要把關的環節

Codex 擅長範圍明確、結果能被驗證的開發工作，例如解釋專案、做一個聚焦的修改、協助除錯、跑本機審查、在 CI 腳本中自動化。OpenAI 在 Quickstart 給的範例提示，是請它檢視應用程式、找出一項影響明顯的易用性改善、實作、更新相關測試，並在手機與桌面版面驗證結果。這類任務的共同點是做完之後有東西可以檢查。

不擅長的則是範圍模糊、又沒有測試可驗證的任務。這種任務交給誰都難以判斷做得對不對，Codex 也不例外。

依 OpenAI 的說明文件，雲端版適合四種情境：

1. 工作本來就該在遠端執行。
2. 多個任務要共用同一套環境設定。
3. 流程需要用到服務憑證。
4. 要從終端機送出雲端任務，或追蹤近期雲端對話的狀態。

CLI 則適合這四種情境：

1. 習慣在終端機裡工作。
2. 需要接進腳本或 CI。
3. 送出前想先做一輪本機審查。
4. 想把工作先交到雲端，稍後再回來接手。

兩張清單的最後一項指的是同一個用法，也就是在終端機用 codex cloud 把任務送上雲端，所以這兩個入口並不互斥。

不管選哪個入口，有幾件事仍然要自己把關。合併之前一定要看過 diff 與測試結果；任務前後各建一個 Git checkpoint，需要時才退得回去；不要隨便用完整存取，也不要把 Codex 暴露在不受信任的環境。介面與預設值會隨版本調整，動手之前請以 OpenAI 當下的說明頁為準。

Codex 的好用程度，取決於你交給它什麼樣的任務。先從一個範圍小、能用測試驗證的修改開始，確認權限停在你放心的位置，再逐步把更大的工作交出去。