Windows Desktop replaces healthy local Codex sidebar with ChatGPT shell when /wham/tasks/list returns 503
What version of the Codex App are you using (From “About Codex” dialog)?
26.715.4045.0
What subscription do you have?
Education
What platform is your computer?
Windows 11 x64
What issue are you seeing?
During an active local Codex task, the merged Desktop sidebar progressively showed fewer tasks, briefly appeared to show unrelated online ChatGPT conversations, and then switched to a generic ChatGPT shell. The active local task title remained visible, but its content stayed blank/loading. The sidebar displayed Aufgaben konnten nicht geladen werden (Tasks could not be loaded). This happened twice in the same app version.
The local app-server was healthy at the same time. At 2026-07-19T14:15:08.804Z, thread/list completed with errorCode=null in 7 ms. Starting less than one second later, the merged shell repeatedly requested:
/wham/tasks/list?limit=20&task_filter=current
and received:
HTTP 503 Service Unavailable
code=biscuit_baker_service_me_circuit_open
Those task-list failures continued through at least 14:20:55Z. Account-check, account-settings, and usage requests returned the same 503 during the interval.
This was not local task loss:
state_5.sqlitestill contained241thread rows.241session JSONL files remained under%USERPROFILE%\.codex\sessions.- The current task rollout remained present and continued running.
- No state repair or database write was performed.
The first app restart restored the task UI, but the bottom-left account area showed only Einstellungen with a gear icon instead of the institution label. A second restart restored the institution label and normal operation.
The failure then reproduced again after approval activity. The restarted process had already accumulated 26 /wham/tasks/list HTTP 503 responses, so the approval did not create the outage. The useful correlation is that approval completion triggers or accompanies account refresh:
14:42:19Z-14:42:23Z four command approvals accepted
14:42:23.254Z account/read completed
14:42:27.592Z /wham/tasks/list -> 503
14:42:28.647Z /wham/tasks/list -> 503
14:42:30.880Z /wham/tasks/list -> 503
14:42:34.938Z /wham/tasks/list -> 503
14:43:24.361Z file-change approval accepted
14:43:24.416Z account/read completed
Immediately after the final approval, the sidebar again showed cloud ChatGPT items and then Tasks could not be loaded. This suggests account/sidebar refresh exposes an already failed remote task source and replaces cached/local Codex state.
What steps can reproduce the bug?
The service-side circuit-open condition was observed rather than intentionally induced:
- Keep an active local Codex task open in Desktop.
- Let
/wham/tasks/listreturn HTTP 503 while local app-serverthread/listremains successful. - While the app still renders cached/local task state, accept a command or file-change approval that is followed by account/sidebar refresh.
- Observe the sidebar progressively lose tasks, briefly show cloud ChatGPT conversations, and switch from the Codex project/task view to the generic ChatGPT shell.
- Observe Tasks could not be loaded and a blank/loading active task.
- Restart the app and observe that recovery may be staged, with the task UI returning before account/institution identity.
What is the expected behavior?
A remote ChatGPT task-list or account-metadata outage should not replace or hide healthy local Codex tasks.
When /wham/tasks/list fails but local thread/list succeeds, Desktop should retain the local Codex sidebar and active task across account refreshes and approval completion. Remote-only features may show a non-blocking error, but the app should not switch to an unrelated ChatGPT history surface or require repeated restarts to restore account identity.
Additional information
Closest related reports:
- openai/codex#30409 requests graceful degradation when boot-time ChatGPT metadata calls fail, but reports a full-screen Oops error on macOS rather than this Windows generic-shell fallback.
- openai/codex#33029 covers custom-provider sessions blocked by unreachable ChatGPT metadata endpoints.
- openai/codex#30806 covers missing history with
/wham/tasks/list401 responses. - openai/codex#17540 covers older local sidebar threads missing after restart while remaining on disk.
- openai/codex#34089 reports a blank Windows root route in the same app version while
/wham/tasks/listreturned 200.
A screenshot and a redacted desktop-log excerpt are available. The screenshot shows the generic ChatGPT shell, the active Codex task title, and Aufgaben konnten nicht geladen werden simultaneously.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Environment
Issue Summary
Received a 503 circuit-breaker error on the Codex desktop app. Shortly after, on the ChatGPT web UI, account state appeared stale/incorrect (old display name, missing chat history).
503 error (Desktop)
unexpected status 503 Service Unavailable: Service Unavailable
url: wss://chatgpt.com/backend-api/codex/responses
cf-ray: a209fbdb3ffc83d5-LAX
auth error: 503
auth error code: biscuit_baker_service_me_circuit_open
Account data anomaly (Web)
Expected behavior
The 503/circuit-breaker event on the backend should not cause the web client to silently roll back or lose current account state (display name, chat history). Account data should remain consistent even during backend service degradation.
Date/time
2026-07-25
Related
Similar to #34183 (Windows Desktop replaces healthy local Codex sidebar with ChatGPT shell when /wham/tasks/list returns 503), but with additional web-side data anomaly not previously reported.
I have the same problem on a Fedora 44, so it doesn't look as only a Windows issue.
I may have encountered a related but more severe failure mode in the merged Windows desktop app: an active long-running local task became absent from Recents and Archived around weekly usage exhaustion, while substantial uncommitted changes remained in the private workspace. Refresh and sign-out/sign-in did not restore the task, and there was no durable task ID/checkpoint available to resume from.
I opened #35784 with sanitized details and a specific request for durable local task persistence, deterministic resume, automatic source checkpointing, and privacy-preserving diagnostics. I am intentionally not publishing raw rollout files, repository identifiers, local paths, prompts, or source code because they contain private workspace information.
The common possibility is that remote/merged task-list state can hide or orphan a healthy local task exactly when account/usage state changes. If local
thread/listor session data survives, the UI should never replace it with an incomplete remote history view.