通过网关使用 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 协作验证通话目标地址和凭据处理方式，然后测试一次完整的语音会话。