通過閘道器使用 ChatGPT 登入
為什麼選擇這種方式
如果你已有模型閘道器，並通過 API Platform 使用 Codex，可以在切換到使用 ChatGPT 登入 時保留閘道器。這樣既能使用符合條件的 ChatGPT 工作區功能和控制項（例如語音模式），又能保留模型閘道器。有關登入方式的比較，請參閱功能可用性。
如何設定
現有的基於命令的身份驗證將閘道器金鑰放在 Authorization 中。使用 ChatGPT 登入時，該請求頭承載的是 ChatGPT 令牌。請選擇提供獨立閘道器憑據的方式：
- 方案 A： 通過一個小型啟動輔助程式複用憑據命令。在單獨的請求頭中傳送同一個閘道器金鑰。
- 方案 B： 讓 Codex 通過原生 OAuth 取得閘道器憑據。
在託管設定中，將所選供應商的設定新增到工作區的雲端託管 requirements.toml 中。這些要求在使用者使用 ChatGPT 登入後生效，不會限制其他登入方式。閘道器相容 Codex 的基礎 URL 必須將 /models 和 /responses 代理到 https://chatgpt.com/backend-api/codex。
方案 A：通過輔助程式複用憑據命令
保留現有的憑據命令。一個小型輔助程式會在啟動 Codex 前執行該命令，並將其輸出匯出為 GATEWAY_KEY。這與當前使用的閘道器金鑰相同，只是改用另一個請求頭傳遞。
例如，現有的 API/供應商設定可能包含：
# config.toml — existing API/provider setup
model_provider = "enterprise_gateway"
[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/v1"
requires_openai_auth = false
[model_providers.enterprise_gateway.auth]
command = "/usr/local/bin/fetch-gateway-token"要使用 ChatGPT 登入，請將該供應商替換為以下託管設定。移除其中的 auth 設定塊：基於命令的供應商身份驗證不能與 requires_openai_auth = true 結合使用。
# requirements.toml
model_provider = "enterprise_gateway"
[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/backend-api/codex" # Keep the gateway route.
requires_openai_auth = true # Use the ChatGPT credential for OpenAI.
env_http_headers = { "X-Gateway-Key" = "GATEWAY_KEY" } # Send the same gateway key separately.為 CLI 使用啟動輔助程式，例如下面的 shell 函式。將命令和參數替換為現有 auth 設定塊中的命令和參數：
codex_with_gateway() (
set -eu
GATEWAY_KEY=$(/usr/local/bin/fetch-gateway-token)
test -n "$GATEWAY_KEY"
export GATEWAY_KEY
exec codex "$@"
)
codex_with_gateway設定閘道器，使其接受 X-Gateway-Key、驗證金鑰，並在將請求轉發到後端前移除該請求頭。客戶端發出的請求現在攜帶：
Authorization: Bearer <ChatGPT token>
ChatGPT-Account-ID: <workspace ID, when available>
X-Gateway-Key: <same gateway key returned by your command>輔助程式在每次啟動時執行一次。Codex 不會重新執行它，也不會重新整理此請求頭；金鑰過期後，需要取得新金鑰並重新啟動。對於桌面應用，啟動整合必須向應用程序提供 GATEWAY_KEY。如果希望由 Codex 管理閘道器登入和令牌續期，請選擇方案 B。
圖中簡化了請求頭和啟動輔助程式。請使用 Authorization: Bearer <ChatGPT token>，並保留上述範例中輔助程式對空金鑰的檢查。如果 GATEWAY_KEY 為空，Codex 會省略 X-Gateway-Key。
方案 B：使用原生閘道器 OAuth
此方案通過 Codex 管理的閘道器登入替代命令和啟動輔助程式。閘道器必須具備 OAuth 授權伺服器。註冊一個支援帶 PKCE 的授權碼流程的公共客戶端，然後替換範例中的 URL 和客戶端 ID。移除現有供應商的 auth 設定塊，並使用以下託管設定。
# requirements.toml
model_provider = "enterprise_gateway"
[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/backend-api/codex" # Keep the gateway route.
requires_openai_auth = true # Use the ChatGPT credential for OpenAI.
[model_providers.enterprise_gateway.gateway_oauth] # Add gateway OAuth.
authorization_url = "https://login.example.com/oauth/authorize"
token_url = "https://login.example.com/oauth/token"
client_id = "YOUR_PUBLIC_CLIENT_ID"
delivery = { kind = "cookie", name = "auth-openid" } # Add gateway auth as a cookie.
# redirect_port = 43127Codex 預設使用空閒的環回埠。如果身份供應商要求固定的重定向 URI，請設定 redirect_port，並為此範例註冊 http://127.0.0.1:43127/callback。
新增路由請求頭（可選）
無論使用哪種方案，Codex 都可以向閘道器傳送自定義路由請求頭。例如，在雲端託管的 requirements.toml 中，為同一個 enterprise_gateway 供應商新增以下請求頭：
[model_providers.enterprise_gateway.http_headers]
x-portkey-config = "<gateway-routing-config-id>"
x-portkey-metadata = '{"tool_id":"codex"}'Codex 在模型供應商請求中傳送這些請求頭，閘道器則應用路由規則。對於從 Codex 程序環境中讀取的值，請使用 env_http_headers。測試一個請求，確認閘道器收到這兩個請求頭並選擇了預期路由。有關更多請求頭選項，請參閱自定義模型供應商。
分別處理各自的憑據
Codex 會傳送 ChatGPT 的 Authorization 請求頭、任何 ChatGPT-Account-ID 請求頭，以及閘道器請求頭或 cookie。讓閘道器驗證並移除自己的憑據，然後原樣轉發 ChatGPT 請求頭。
注意事項與限制
- 使用支援託管模型供應商要求的 Codex 版本；對於方案 B，還需支援原生閘道器 OAuth。舊版本可能會忽略或拒絕不支援的欄位。
- 此路由涵蓋通過所選模型供應商發出的請求。ChatGPT 登入、MCP、外掛和其他應用連線可能使用不同的路徑。
- 閘道器可以看到請求資料和兩種憑據。請在日誌中對其進行脫敏；切勿將閘道器憑據轉發到上游。
- 原生閘道器 OAuth 需要瀏覽器和可存取的環回回呼。它不支援裝置程式碼回退方式。如果沒有重新整理令牌，使用者必須在存取令牌過期後重新通過瀏覽器登入。
- 通用的 OpenAI
/v1/models響應並不足夠：Codex 需要一個models陣列。請測試模型列表、一個提示詞，以及部署中使用的每項功能。
通過閘道器使用語音
此設定為 Codex 模型供應商請求設定路由，並不會啟用 ChatGPT 語音。對於 WebRTC 語音會話，通話建立和邊帶連線使用不同的路由。~/.codex/config.toml 中的實驗性 experimental_realtime_webrtc_call_base_url 設定僅更改用於建立通話的 HTTP 基礎 URL，不會重定向邊帶連線、媒體或普通模型請求。在使用此覆蓋設定前，請與 OpenAI 協作驗證通話目標地址和憑據處理方式，然後測試一次完整的語音會話。