[Bug]: Codex OAuth 连接失败无任何错误提示，且残留空的 codex-auth.json #472

Activity

1. hetaoBackend

   added

   bugSomething isn't workingSomething isn't working

   desktopMiniMax Code desktop appMiniMax Code desktop app

   on Oct 13, 2026
2. hetaoBackend commented on Oct 13, 2026

   

   hetaoBackend

   on Oct 13, 2026

   Collaborator

   More actions

   Thanks for the report. Two symptoms are described here — the missing error message and the leftover empty codex-auth.json — and both are worth fixing.

   Triage action: labelled bug + desktop. Removed from needs-triage.

   What we need to reproduce it (please reply with these):

   1. The resolved path of the leftover codex-auth.json, and whether the file is empty (0 bytes) or contains a partial/expired token.
   2. Whether the failure happens both when the browser flow is completed and when the browser window is closed mid-flow.
   3. Whether the "connect" action shows any state change at all in the settings panel, or only silently resets.

   If it reproduces again, a desktop log upload ID from Settings → General → Upload logs would let us correlate it with the client-side state. We will reply within 48 hours. If you want to fix it yourself, a fork PR does not require collaborator access — please open an issue describing the scope first.
3. Rainlvan commented on Oct 13, 2026

   

   Rainlvan

   on Oct 13, 2026

   Author

   More actions

   Thanks for the triage. Answering your three questions:

   1. Leftover codex-auth.json — path and contents

   Resolved path: C:\Users\Ren\.minimax\codex-auth.json (this is the <dataDir> for the default profile).

   The file is 2 bytes and contains exactly {} — i.e. completely empty. No partial token, no expired token, nothing. It is created at the moment the flow starts (first observed at 01:25:28) and is never written to again.

   For reference, once connected successfully, the same file is 2364 bytes with an openai-codex entry of type: oauth.

   2. Both completed and interrupted flows?

   Yes — both.

   • Completed flow: browser reached "身份验证成功", but the file stayed {}.
   • Interrupted flow: closing the browser window mid-flow also leaves {}.

   Observed sequence (UTC+8), all 8 attempts left the file empty:

   01:25:28  file created ({}), flow abandoned mid-way
   01:29:30  POST -> browser completed auth, still {}
   01:33:34  POST -> still {}
   01:33:51  POST -> still {}
   01:34:49  POST -> still {}
   01:35:46  POST -> still {}
   01:38:11  POST -> still {}
   

   3. Any state change in the settings panel?

   No. The panel stays on "暂无添加自定义模型" and no error, toast, spinner or state change is shown. Screenshot taken at 01:37 — after five attempts — shows the same state as before the first attempt.

   Caveat on confidence here: I have before/after screenshots rather than continuous observation of every attempt, so I can't rule out a brief transient state I didn't capture. What I can state firmly is that nothing persisted and no error was surfaced.

   4. Log upload ID

   Not yet available. I'll generate one via Settings → General → Upload logs and post it as a follow-up here, since it needs a GUI action on my side.

   One more data point that may help narrow it: the runtime log records request status codes and durations for /mavis/api/provider-auth/openai-codex, but not response bodies. Every request returned 200. That is why I could not determine whether the OAuth callback ever reached the local listener — the information needed to pinpoint the failure simply isn't in the logs. Logging the (redacted) auth flow state or error code would make this diagnosable.

   ---

   Related: #473 (Codex model catalog) was fixed in #477 — thanks for the quick turnaround. That one is confirmed resolved on the source side.
4. Rainlvan commented on Oct 13, 2026

   

   Rainlvan

   on Oct 13, 2026

   Author

   More actions

   Desktop log upload ID, plus a new reproducible failure found while gathering it.

   Log upload ID

   UploadId: 519560583918653441/logs_20261013-20261013_1791901791461.zip
   

   Uploaded via Settings → General → Upload logs, 13 diagnostic artifacts, upload confirmed successful at 22:29:52 local.

   New finding: MODEL_DISCOVERY_FAILED is reproducible on demand

   While collecting the ID above I hit a different but adjacent failure that I can reproduce reliably, so recording it here while it's fresh:

   [22:08:18.877] POST /mavis/api/provider-auth/openai-codex/models  status=502  durationMs=298
   [22:08:35.975] POST /mavis/api/provider-auth/openai-codex/models  status=502  durationMs=239
   

   • Trigger: backend host unreachable from the client.
   • 22:08 — backend unreachable → both attempts 502, UI shows:

     获取模型列表失败，已保留原有设置。请点击"获取模型列表"重试。

   • 22:18 — backend reachable → same button succeeds ("模型列表已更新").

   Same app build (3.1.1.178), same credentials, same session. The only variable was backend reachability.

   Two problems with the error surfaced to the user

   1. The message doesn't indicate the cause. "Failed to fetch model list… please retry" reads as an application fault and invites a pointless retry. It gave me no way to tell "the network can't reach the backend" from "the product is broken" — I initially reported the latter. For users behind a proxy or on a restricted network, this is the difference between a one-minute fix and an open-ended bug hunt.

   2. Credentials and provider config are kept, so the UI looks fine. The provider still renders as connected with all models listed, and every one of them fails at inference. A listed model that cannot be called is more misleading than an empty list.

   Environment context

   This machine is in mainland China, where chatgpt.com requires a proxy. So "backend unreachable" is a routinely reachable state for a subset of users, not an edge case. If the failure path distinguished transport failure from other errors — or surfaced the underlying cause — it would save a lot of confusion.

   ---

   Not filing this as a separate issue yet, since it may be the same failure surface as the original report. Happy to split it out if you think it warrants its own issue.

   Environment: MiniMax Code 3.1.1.178, Windows 11 x64 (10.0.26300).