Codex 登入成功，不等於 API 已經呼叫成功
Codex 顯示「登入成功」，是否代表 API 已經能呼叫？還差一步驗證。本地記錄了認證狀態、在線請求成功、任務通過驗收，是三件不同的事。
原實驗用一個故意無效的測試輸入，檢查 CLI 的本地登入提示，沒有發起模型請求。
第一關：確認本地認證方式
codex login status
2026年10月21日，在隔離目錄中使用 Codex CLI 0.163.0，故意無效的測試 Key 也讓登入指令顯示 Successfully logged in，隨後狀態指令退出碼為0。
這證明的是該版本能夠儲存並識別本地認證狀態，沒有證明 Key 有效、模型權限正確或網絡請求成功。原帳戶憑據沒有被修改，實驗後清除了隔離目錄的測試登入狀態。
官方指令文件也說明，存在憑據時 codex login status 返回0。Codex login 說明
有自己的有效 Key 時，怎樣傳給 CLI
前提是在當前終端機中已經設定好自己的 OPENAI_API_KEY。通過標準輸入傳入，不把真實 Key 直接寫進公開示例：
Windows PowerShell：
$env:OPENAI_API_KEY | codex login --with-api-key
macOS / Linux：
printenv OPENAI_API_KEY | codex login --with-api-key
這只是官方 Key 的認證路徑，第三方供應商還需要對應模型與端點設定。不要分享 auth.json、Authorization 頭或真實 Key。官方認證與憑據儲存說明
第二關：實際請求有沒有成功
準備好自己的權限和費用設定後，在空測試目錄做一個小任務，例如列出當前目錄檔案且不修改。核對實際返回、使用的模型與後台用量。
這一步可能產生 API 用量，是建議的後續驗證，不是上述本地實驗已經完成的結果。
第三關：任務有沒有做對
如果要求修改程式碼，再檢查改動範圍與測試結果。收到回答不等於功能正常，執行完成也不等於驗收通過。
求助時寫清版本、認證類型、剛執行的步驟和已遮去敏感資料的錯誤，比只發「明明已經登入」更容易定位。原稿於2026年10月27日整理，保留原 CLI 版本與實驗邊界，沒有重新執行或進行付費呼叫。
香港繁體版整理日期：2026年10月28日。原文引用的產品說明核對截至2026年10月27日；原實驗日期與範圍保留於文中。