503 from /v1/responses via Codex even though direct proxy curl to same endpoint returns 200 OK (Xiaomi MiMo provider, openai-chat adapter)

Client or integration

Codex App

Area

CLI

Summary

The opencodex proxy returns 503 to Codex on /v1/responses even though the identical request succeeds with 200 OK when curl'd directly at the same endpoint. I expected Codex to receive the same successful response the proxy already returns.

Reproduction

ocx uninstall && npm install -g @bitkyc08/opencodex && ocx init
Configure provider "xiaomi" with adapter openai-chat, baseUrl https://api.xiaomimimo.com/v1, valid API key, defaultModel mimo-v2.5-pro. Set defaultProvider to "xiaomi".
ocx sync && ocx start (proxy confirmed healthy via GET /healthz)
Send: curl -v http://127.0.0.1:10100/v1/responses -H "Content-Type: application/json" -d "{"model":"mimo-v2.5-pro","input":"hi"}"
-> returns 200 OK with a valid response.completed payload containing real text from the model.
Run: codex -m "mimo-v2.5-pro" "hi" (also reproduced via the Codex model picker, which shows the model as "xiaomi/mimo-v2.5-pro")
Observe: unexpected status 503 Service Unavailable: Unknown error, url: http://127.0.0.1:10100/v1/responses

Also worth noting: before removing the provider prefix, selecting "xiaomi/mimo-v2.5-pro" in the Codex model picker (while authenticated via ChatGPT account, not API key) returned:
"The 'xiaomi/mimo-v2.5-pro' model is not supported when using Codex with a ChatGPT account."
This matches known upstream Codex behavior rejecting slash-prefixed model names under ChatGPT-account auth (openai/codex#12295). Removing the prefix and calling the bare model name still results in 503 rather than success, despite the identical payload working when curl'd directly.

Additionally, after this started happening, previously-working providers (an NVIDIA-hosted GLM model, configured separately) also began returning 503, suggesting the issue may not be provider-specific but related to how Codex's ~/.codex/config.toml injection interacts with openaiProviderTierVersion: 2 under ChatGPT-account auth.

ocx debug provider on / ocx debug provider logs -f produced no visible output even when ocx debug provider status confirmed "on" after restart, so I could not capture the actual outbound request/response opencodex made on Codex's behalf.

Version

2.7.39

Operating system

Windows 11

Provider and model

xiaomi (openai-chat adapter) / mimo-v2.5-pro

Logs or error output

unexpected status 503 Service Unavailable: Unknown error, url: http://127.0.0.1:10100/v1/responses
ocx status:
✅ Proxy: running
   Health: http://127.0.0.1:10100/healthz ok, version 2.7.39
   Default provider: xiaomi

Direct proxy curl (succeeds):
HTTP/1.1 200 OK
{"id":"resp_...","object":"response","status":"completed","model":"mimo-v2.5-pro","output":[{"type":"message","role":"assistant","status":"completed","content":[{"type":"output_text","text":"Hello! ..."}]}]}

Screenshots and supporting files

No response

Redacted configuration

{
  "port": 10100,
  "providers": {
    "xiaomi": {
      "adapter": "openai-chat",
      "baseUrl": "https://api.xiaomimimo.com/v1",
      "apiKey": "<REDACTED>",
      "defaultModel": "mimo-v2.5-pro"
    }
  },
  "defaultProvider": "xiaomi",
  "openaiProviderTierVersion": 2,
  "codexShimAutoRestore": true,
  "websockets": false,
  "codexAutoStart": true
}

Checks

I searched existing issues and documentation.
I removed secrets, tokens, account details, request credentials, and personal data.

fix(ci): silence English translation bookkeeping and harden related-i…

@ttexxs12

Diagnosis

Codex's Unknown error is not a Xiaomi-specific message. In Codex (UnexpectedResponseError), Unknown error means the HTTP response body was empty.

That rules out the normal openai-chat error path: those failures are wrapped as JSON via formatErrorResponse and would surface as Provider error NNN: ..., not Unknown error.

Minimal curl succeeding while Codex fails is expected: Codex sends streaming / tool-rich / ChatGPT-account traffic (including WS probe + helper/shadow models), which can hit the openai-responses passthrough. Passthrough currently relays non-JSON / empty upstream 5xx bodies verbatim — so a ChatGPT 503 with an empty body becomes exactly:

unexpected status 503 Service Unavailable: Unknown error, url: http://127.0.0.1:10100/v1/responses

That also explains other providers suddenly failing: a shared ChatGPT/passthrough call in the session can fail even when the selected routed model is healthy.

Empty ocx debug provider logs is also expected today: openai-chat has no debugProviderDiagnostic hooks (only kiro/cursor do). Use GET /api/logs while reproducing.

Fix in progress

Never relay empty / non-JSON upstream errors from passthrough — wrap with formatErrorResponse so Codex always gets a message.
Make drain 503 responses JSON (same envelope) instead of plain Service shutting down.
Add debugProviderDiagnostic to openai-chat so provider debug logs actually capture Xiaomi/openai-chat traffic.
Focused regression tests for empty-body passthrough 503 and JSON drain responses.

While waiting — quick checks

@ttexxs12

During a Codex failure:

curl -s http://127.0.0.1:10100/api/logs

Inspect provider, providerAdapter, status, upstreamError. If providerAdapter is openai-responses, that confirms the passthrough path.

Also compare:

curl -s http://127.0.0.1:10100/v1/responses -H "Content-Type: application/json" -d "{\"model\":\"mimo-v2.5-pro\",\"input\":\"hi\",\"stream\":true}"

Implemented

PR: #463

Shipped:

Passthrough empty/non-JSON upstream errors → JSON formatErrorResponse (preserves OpenAI-style {error.message} when present)
Drain 503 → JSON envelope with server_is_overloaded + Retry-After: 5
openai-chat debugProviderDiagnostic on request / stream-error / stream-truncated
Tests in tests/issue-452-empty-503.test.ts

After this lands, a ChatGPT empty-body 503 should show something like Provider error 503: (empty body) instead of Codex Unknown error. Use ocx debug provider on + ocx debug provider logs -f for openai-chat traffic, or GET /api/logs.

fix(proxy): stop surfacing empty 503 bodies as Codex Unknown error

Merge pull request #463 from Wibias/fix/issue-452-opaque-503

Reopen please, when u got some info.

test(codex): follow #2398 on the oversized pool-retry 400 body (#2404)

Merge from upstream (#8)

fix(ci): silence English translation bookkeeping and harden related-i…

fix(proxy): stop surfacing empty 503 bodies as Codex Unknown error

fix(proxy): only wrap empty passthrough error bodies

Merge pull request lidge-jun#463 from Wibias/fix/issue-452-opaque-503

test(proxy): align lidge-jun#452 Retry-After: 0 expectation with clie…

test(codex): follow lidge-jun#2398 on the oversized pool-retry 400 bo…

Navigation Menu

Repository navigation

503 from /v1/responses via Codex even though direct proxy curl to same endpoint returns 200 OK (Xiaomi MiMo provider, openai-chat adapter) #452

Client or integration

Area

Summary

Reproduction

Version

Operating system

Provider and model

Logs or error output

Screenshots and supporting files

Redacted configuration

Checks

Diagnosis

Fix in progress

While waiting — quick checks

Implemented

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

503 from /v1/responses via Codex even though direct proxy curl to same endpoint returns 200 OK (Xiaomi MiMo provider, openai-chat adapter) #452

Description

Client or integration

Area

Summary

Reproduction

Version

Operating system

Provider and model

Logs or error output

Screenshots and supporting files

Redacted configuration

Checks

Activity

Wibias commented on Jul 25, 2026

Diagnosis

Fix in progress

While waiting — quick checks

Wibias commented on Jul 25, 2026

Implemented

Wibias commented on Jul 25, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions