[Windows Desktop][26.924.2738.0] Loading spinner after reopening while active chats remain listed (follow-up to #45886) #48625

What version of the Codex App are you using?

Windows package OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0, verified using Get-AppxPackage on September 27, 2026 (rather than the About dialog).

Bundled/copied desktop backend: codex-cli 0.158.0-alpha.2.1. Separately installed CLI: codex-cli 0.157.1.

The installed Start-menu entry/window is branded ChatGPT, the package identity is OpenAI.Codex, and its desktop executable is app/ChatGPT.exe.

What subscription do you have?

Not collected during this investigation.

What platform is your computer?

Windows 11 Home 25H2, x64, build 26200.9550.

What issue are you seeing?

The desktop app cannot reliably return to a usable state after closing and reopening it. A previous local troubleshooting session got the interface working, but the recovery has not persisted across launches, and freezes have become frequent.

Clarification of the visible symptom: the main desktop window exists but stays on a loading circle/spinner. Right-clicking the app shows active chats. My initial description that nothing appeared meant that the usable interface did not load; it did not mean there was no window.

I am communicating with the investigating assistant through the command-line interface, not the stalled desktop window. I can also work with this PC through mobile remote access and started a task from there. These are user-reported observations: they show that other interaction paths remain available, but do not establish completion of that task or the cause of the desktop spinner.

This is a follow-up to #45886, which is closed. That older report concerned the disabled Send button after the first turn. Its closure explanation described a local recovery of renderer queries involving codex-home, not a confirmed permanent product fix. I already added a September 27 recurrence comment, including that a command-line launch helped temporarily but reopening subsequently failed.

The current symptom can prevent reaching a usable desktop interface at all. I am linking the history without assuming the earlier composer problem and this startup problem have the same root cause.

What steps can reproduce the bug?

User-observed sequence on the affected installation:

1. Get the desktop app open after temporary local troubleshooting/recovery.
2. Close the app.
3. Launch the installed desktop app again.
4. The main window remains on a loading circle/spinner instead of loading the usable interface. The app's right-click menu still shows active chats.

This is a startup/reopen problem, so no particular conversation, prompt, token limit, or context-window usage is required to describe it. A clean-profile minimal reproduction has not been established on this machine.

What is the expected behavior?

Closing and reopening the app should reliably restore a visible, usable interface without renderer reloads, backend reconnection, configuration replacement, or manual diagnostic launch steps.

Additional information

Earlier September 27 local recovery, recorded in the local diagnostic report:

• At a stalled loading screen, the renderer's local app-server version was null although authentication had finished and the backend had initialized. The installed renderer code was observed to wait for this version during readiness.
• Reloading the renderer, or reconnecting the desktop app server, restored the sidebar, projects and composer. Neither established a permanent fix or successful ordinary reopen cycle.
• Disabling GPU acceleration and regenerating the JavaScript code cache did not resolve the cold-start failure. The original cache and normal graphics settings were restored.
• The final launch in that investigation used the normal Windows package entry point. No vendor binary fix was applied. A real new message was not submitted through the recovered composer.

These are findings from the saved earlier investigation, not newly repeated recovery experiments in this reporting session.

Current read-only verification on September 27:

• Windows reports the installed package as OK. The main desktop process and renderer subprocesses are running. Window inventory reports one ChatGPT window. The user subsequently clarified that this window is visible but stuck on a loading circle, while right-clicking the app shows active chats. Window existence and ready-to-show events therefore do not establish a usable main interface.

• The current main process started at 03:39:43 UTC, with no remote-debugging or disable-GPU arguments. Its two newest desktop log files are zero bytes, so they provide no diagnostic detail about the user-reported reopen failure.

• Earlier same-day logs contain primary window ready-to-show events, including 03:23:26.823 UTC and 03:27:58.125 UTC. These events alone do not establish usable UI or successful reopening.

• Windows AppModel-Runtime recorded this warning at 03:27:32.308 UTC:

  Event 208: 0x8000001A: Cannot create the process for package
  OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0 because an error
  was encountered while configuring runtime. [LaunchProcess]
  

  A later launch reached ready-to-show. The relationship of this isolated activation warning to the recurring symptom is unknown.

• No matching Codex/ChatGPT Application Error, Windows Error Reporting, or Application Hang events (1000/1001/1002) were found in the preceding 12-hour query. This does not rule out a hang or unlogged failure.

• The inspected nonempty desktop logs did not establish a codex-home timeout, stale application lock, or renderer crash. Statsig bootstrap timeouts and thread-hydration errors also appear, but their causal relationship to reopening is unproven.

I have preserved the app state during this reporting session: no forced quit, profile reset, reinstall, cache deletion, or backend reconnection. The close/reopen sequence above remains user-reported; it was not forced again while the investigation was active.

Related open reports found before filing: #48492 reports the same package working once with fresh configuration and then hanging on reopen; #48463 and #48594 also describe startup/restart failures on this package. These may be related, but identical root cause is not established. Please link or consolidate this follow-up with the appropriate investigation if useful.

Please investigate why recovery does not survive a normal close/reopen cycle, including renderer readiness/version delivery and Windows package activation. Guidance for collecting a supported startup trace while preserving existing chats and projects would help.

Only sanitized technical facts are included here. Raw logs, account identifiers, tokens, conversation contents, private paths and project information have not been attached.