Codex CLI 的憑證問題，歸根結底都是三個問題：你用的是哪種登入方式？這份憑證存放在哪裡？此刻真正生效的又是哪一種？答案決定了用量如何計費、你的安全評審該是什麼樣，以及該走哪條排查路徑。官方認證文件列出了全部三條路徑及其儲存行為，本文把它們整理成一幅可直接上手的圖景。本文是對我們此前介紹的Claude Code 憑證優先順序一文的有意呼應；兩篇合起來，構成雙 agent 工具鏈的憑證參考，且彼此不重複對方的機制。如果你是全新搭建而不是審查一臺現成的機器，那麼工具配置指南是更好的起點。
三條登入路徑
使用 OpenAI 模型時，Codex 支援兩種人工登入方式：使用 ChatGPT 登入，用於訂閱訪問；以及使用 API key 登入，用於按用量訪問。兩者在桌面應用、CLI 和 IDE 擴充套件中都可用；Codex cloud 則要求使用 ChatGPT 登入。企業自動化還有第三條路徑：Codex 訪問令牌，詳見下文。
這個選擇並非無關緊要。根據官方認證文件，登入方式決定了適用哪些管理控制與資料處理策略：ChatGPT 登入遵循你的 ChatGPT 工作區許可權、基於角色的訪問控制，以及 Enterprise 的保留與駐留設定；而 API key 用量則改為遵循你的 API 組織的保留與資料共享設定。如果你的組織要審計資料流，這一句話就決定了你該和合規團隊開哪一場會。
CLI 的預設方式是瀏覽器流程：執行codex login並完成瀏覽器中的步驟。當沒有可用的有效會話時，這就是 Codex 首先提供的路徑。
Codex CLI 的 API key 登入，以及它如何計費
API key 這條路徑更多是為機器和流水線設計的，而不是為人工操作設計的。Codex 不把 key 作為命令列引數接收（那樣它會落進 shell 歷史和程序列表），而是從標準輸入讀取：
printenv OPENAI_API_KEY | codex login --with-api-key這一條命令就是 codex login 的 API key 流程，而它的計費含義值得讀兩遍。OpenAI 通過你的 OpenAI Platform 賬戶按標準 API 價格對 API key 用量計費，Codex 使用標準 API 定價，而不是 ChatGPT 套餐內含的額度。換句話說，這樣登入會把你從訂閱世界帶進按量計費世界，具體價格見官方定價頁，本文不展開。功能覆蓋也會變化：文件指出，部分依賴 ChatGPT 工作區訪問或雲服務的功能在 API key 認證下會受限或不可用，某些外掛也不可用，因為它們的連線流程需要 OAuth 能力，而這一模式不提供。
這一模式的優勢在自動化。文件說得很直接：程式化的 Codex CLI 工作流（例如 CI/CD 任務）請使用 API key 認證，並且不要在不可信或公開環境中暴露 Codex 執行。
Codex CLI 憑證在磁碟上：四種儲存模式
登入之後，憑證會被快取。文件明確說明，Codex 會把登入資訊快取在本地的明文檔案裡，~/.codex/auth.json或者放在作業系統的憑證儲存中；同時 CLI 與 IDE 擴充套件共享同一份快取的登入資訊。如果這篇文章你只記一句話，就記文件自己的那句：如果你使用基於檔案的儲存，請把~/.codex/auth.json它當作密碼對待，因為它包含訪問令牌。不要提交到倉庫，不要粘進工單，也不要在聊天中分享。
快取落在哪裡，可以通過配置裡的cli_auth_credentials_store來設定。文件給出四種模式：
file把憑證存進auth.json目錄下，CODEX_HOME該路徑預設為~/.codex。keyring把憑證存進作業系統的憑證儲存，如果該儲存不可用就直接失敗，而不是靜默回退。auto在有可用的作業系統憑證儲存時使用它，否則回退到auth.json。ephemeral只在當前程序的記憶體中保留憑證，適合不應向磁碟持久化任何內容的一次性環境。
完整的 schema 見配置參考。對受管機群來說，有一個治理細節很重要：管理員可以通過本地認證要求強制cli_auth_credentials_store，而使用者無法通過config.toml或 CLI 引數覆蓋被強制的值。如果你的平臺團隊希望作業系統憑證儲存成為 Codex auth.json 這類金鑰唯一可接受的位置，那麼這個開關是存在的，而且它不是建議性的。
檢查當前生效的是哪種登入
兩條命令就能回答狀態問題：codex login status會報告當前生效的認證方式，而codex logout會清除已儲存的憑證。在桌面應用和 IDE 擴充套件中，個人資料選單會顯示當前賬號或 API key 狀態。
共享快取這一行為，解釋了一整類團隊困惑。由於 CLI 與擴充套件共享快取的登入，其中任意一方登出，就意味著另一方下次啟動需要重新登入。當同事說“我這兒能跑，他那兒不行”時，某個介面最近發生過登出，屬於頭號嫌疑，而不是邊緣情況。
文件裡有一條企業邊界值得單獨說明：當程序環境選擇了 workload identity 時，Codex 會同時拒絕codex login和codex logout，因為認證由外圍環境控制。在這種配置下，登入命令並不是你要找的介面，這是有意為之。
Codex 無頭登入：裝置碼與備選方案
基於瀏覽器的登入，前提是有瀏覽器且本地回撥可用。在遠端或無頭機器上，或者當本地網路阻斷把 OAuth 令牌返回給 CLI 的 localhost 回撥時，這個前提就不成立了。文件首選的答案是裝置碼認證，目前標記為 beta：
- 個人賬號請在 ChatGPT 安全設定中啟用裝置碼登入；如果工作區由管理員管理，則在工作區許可權中啟用。
- 在執行 Codex 的終端裡，在互動式登入介面中選擇使用裝置碼登入，或者直接執行專用命令：
codex login --device-auth。 - 在瀏覽器中開啟打印出的連結，登入，然後輸入一次性程式碼。
如果你的環境中沒有裝置碼登入，文件給出了兩種備選方案。第一種是在有瀏覽器的機器上完成認證，再把快取的憑證複製到無頭主機，可以藉助scp，或直接複製進容器；文件再次強調了複製檔案的密碼級警告，並指出當你的作業系統把憑證存進憑證儲存而不是檔案時，這個方法可能不適用。第二種是通過 SSH 轉發 CLI 的本地回撥埠，讓標準瀏覽器流程走隧道。兩個流程都有精確步驟的文件，在把它們接進自動化配置之前，都值得在當前頁面重讀一遍，因為 beta 狀態和介面措辭都可能變化。
CI/CD 與自動化
對流水線來說，文件給出的預設做法是 API key 認證，並附帶警告：不要在不可信或公開環境中暴露 Codex 執行。這正好對應CI 指南裡的護欄習慣：通過金鑰儲存注入憑證，只暴露給需要它的那一步，並讓它們遠離日誌和構建產物。
對於需要在自動化中使用 ChatGPT 側會話的團隊，有一種進階模式：一份專門指南介紹瞭如何在可信的 CI/CD runner 上維護賬號認證，包括讓 Codex 在正常執行中重新整理 auth 快取，併為下一個任務保留更新後的檔案。文件也很坦率：API key 仍然是自動化場景推薦的預設選擇；進階路線是為更窄的場景存在的，不是省事的路徑。如果你們組織的憑證按計劃輪換，關於如何在不中斷服務的情況下更換的機械式清單，在提供商切換指南中。
前面提到的 Codex 訪問令牌是第三條路徑：在 ChatGPT Enterprise 工作區中，管理員可以授予訪問令牌許可權，讓成員為可信的非互動式工作流建立令牌。令牌面向可信指令碼、排程器和私有 CI runner，文件的邊界很清楚：一般的 OpenAI API 呼叫，繼續使用 Platform API key。
團隊級管理的限制
受管環境可以在配置層約束認證。文件中兩個設定承擔了主要工作：forced_login_method接受一個只允許 ChatGPT 登入或只允許 API key 登入的取值，而forced_chatgpt_workspace_id把 ChatGPT 登入固定到特定工作區。執行模型很嚴格：如果當前生效的憑證與配置的限制不匹配，Codex 會讓使用者登出並退出。這些也可以通過舊版受管配置提供，所以在管理良好的機群上，“為什麼 CLI 啟動時把我登出了”這個問題，答案可能是策略，而不是 bug。
還有一條來自 Work Cloud 一側的邊界：API key 和 Codex 訪問令牌都無法啟用 Work Cloud 的本地計算機訪問。該能力依賴以 ChatGPT 登入到符合條件的工作區，再多令牌配置也替代不了。
登入診斷
當瀏覽器登入或裝置碼認證失敗時，Codex 會在配置的日誌目錄下寫一個專門的codex-login.log檔案，這個檔案正是文件為登入相關除錯推薦的，也包括提交支援請求時的使用。升級之前先把它收集齊；這決定了你得到的是“登入不工作”，還是一份別人能據此行動的報告。
還有兩個相鄰的細節能省時間。第一，在帶 TLS 代理或私有根 CA 的企業網路中，登入前先把CODEX_CA_CERTIFICATE設定為一個 PEM 包；當它未設定時，Codex 會回退到SSL_CERT_FILE。同一套自定義 CA 設定適用於登入、普通請求和安全 WebSocket 連線，所以這類網路上的登入失敗，往往與後續的請求失敗是同一個根因。第二，對於認證問題裡的錯誤碼層面，通用的錯誤碼指南覆蓋了 401 系列，以及什麼時候不該重試。
如果用的是非預設提供商，先把提供商配置確認清楚，再歸咎於認證；自定義提供商指南把配置失敗與登入失敗區分開來。
速查表與安全清單
| 場景 | 建議路徑 | 憑證所在位置 |
| :- | :- | :- |
| 本地單機 | ChatGPT 登入（預設） | 作業系統憑證儲存或~/.codex/auth.json |
| 本地 + API 計費 | 通過 stdin 的 API key 登入 | 同一儲存，API key 憑證 |
| 共享多使用者機器 | API key，配合每使用者CODEX_HOME，或 keyring 模式 | 僅使用者級儲存 |
| 無頭伺服器 | 裝置碼登入（beta）或文件中的備選方案 | 檔案快取，密碼級 |
| CI/CD | API key 認證 | CI 金鑰儲存，按步驟注入 |
| 受管團隊 | 以forced_login_method允許的為準 | 由受管配置強制執行 |
五個值得刻在心裡的安全動作：把~/.codex/auth.json無論它出現在哪裡都當作密碼對待；永不提交、永不粘進工單、永不在聊天中分享；在策略允許時優先使用作業系統憑證儲存；把 CI 金鑰限定到需要它的那一步，並徹底避免不可信環境；還要記住，CLI 或擴充套件任一方登出都會波及另一方。最後，由於介面措辭和裝置碼上的 beta 標記都可能變化，在把它們寫進 runbook 之前，請對照官方認證頁和平臺自己的文件確認細節。
儲存只是這個問題的一個面；洩漏面、過期、輪換以及“先吊銷”的處理，都彙總在金鑰衛生指南裡。