Codex OAuth: hardcoded `Originator: codex-tui` gets gpt-5.6-sol requests load-shed (`server_is_overloaded`)
已打开 08:29AM - 30 Jul 26 UTC
已关闭 09:04AM - 30 Jul 26 UTC
`gpt-5.6-sol` requests through a Codex OAuth credential fail near-100% while `gp…t-5.6-terra`/`gpt-5.6-luna` work. The upstream response is HTTP 200 whose SSE stream immediately emits `event: error` with `code: "server_is_overloaded"`, then `response.failed` (visible with `request-log: true`). Each failure also puts the auth into cooldown, so most client requests surface as `503 auth_unavailable`, which makes this look like an auth problem.
This is new behavior: the same setup ran cleanly 2026-07-20 through 2026-07-28, failures appeared in bursts during the early hours of 2026-07-29, and again throughout 2026-07-30 00:00–01:30 PT.
A/B probes isolated the trigger to the `Originator` header, which is hardcoded to `codex-tui` (`internal/runtime/executor/codex_executor_request.go`):
- `Originator: codex_cli_rs` (what the current Codex CLI sends): 4/4 success, even with a `curl/8.7.1` User-Agent
- `Originator: codex-tui`: immediate `server_is_overloaded`
- Spoofing only the CLI User-Agent while keeping `codex-tui`: still fails
Workaround: send an `Originator: codex_cli_rs` header on inbound requests — CLIProxyAPI forwards it in place of the default.
Suggested fix: default the originator to `codex_cli_rs`, and/or make it configurable next to `codex-header-defaults`.
Tested on v7.2.92; the constant is unchanged on current main (928478e4).
shiner 08-18 16:251楼
cc 08-18 16:353楼
AeroLoong 08-18 16:364楼
hoshumu 08-18 16:375楼
董炸淘 08-18 17:546楼