[Windows][26.825.5331.0] After Store auto-update, app starts headless for ~12 min — update-policy gate + cua_node runtime re-extraction block window creation; main process event loop synchronously blocked

What version of the Codex App are you using (From “About Codex” dialog)?

26.825.5331.0 (MSIX OpenAI.Codex, auto-updated from 26.820.10647.0 on 2026-08-29)

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Symptom

After the Microsoft Store auto-updated the app from 26.820.10647.0 to 26.825.5331.0, launching it shows only background ChatGPT.exe processes — no window, no error. Windows Event Viewer logs Application Hang 1002. Killing and relaunching reproduced it 4/4 times.

Startup log freezes at exactly 3 lines

[sparkle] in_app_updates_policy_wait_started timeoutMs=300000
Launching app agentRunId=null ... packaged=true platform=win32
Appshot hotkey inactive configured=true enabled=false platform=win32

At that point the process tree has only crashpad-handler / gpu-process / network / storage utilities — no renderer is spawned, all processes report Responding=True with MainWindowHandle=0. No Crashpad dumps.

What unblocks it

Nothing the user does — after 11m47s the main process resumed on its own, and the window appeared within seconds (recovered at 21:50:48 local for a 21:39:01 launch). Earlier attempts were all killed before the stall finished, which made it look like a permanent failure.

Key evidence: the event loop is synchronously blocked

From a 26.820 session on 2026-08-28 with the same freeze signature:

03:27:21.530 [AppServerConnection] app_server_connection.state_changed ... next=connecting
        <-- 8 minute gap, zero log output -->
03:35:33.087 warning Failed to load shell env caller=startup detail="Timed out after 5000ms." durationMs=491923 timeoutMs=5000
03:35:33.088 info [sparkle] in_app_updates_policy_timeout policy=pending timeoutMs=300000
03:35:33.250 info [IpcRouter] I am the router
03:35:38.443 info [window-manager] window main frame finished load
03:35:38.797 info [window-manager] window ready-to-show

Two details matter:

1. A step configured to time out after 5000 ms actually took 491,923 ms.
2. The 5000 ms shell-env timeout and the 300000 ms update-policy timeout fired at the same instant when the stall ended.

Pending timers cannot fire while the main process event loop is blocked — so the startup critical path (shell-env load and/or update-policy wait) is executing synchronously, and its own timeouts are ineffective during the stall.

Runtime re-extraction evidence (likely the trigger)

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\ accumulated 12 stale .staging-* directories: 10 from 2026-08-28 (old runtime hash f24ab376120677c2) and one created at the exact time of tonight's first failed launch (e4d75eceaa042f20 — the 26.825 runtime hash). The app unblocked right after this extraction finished. This matches the mechanisms reported in #41170 and #41056.

Environment notes (ruled out)

• Proxy chain healthy during all failures: SOCKS5 tunnel (127.0.0.1:7897) responds in <1s; chatgpt.com / auth.openai.com reachable; mihomo service logs clean.
• Package status Ok; no PS profile / cmd AutoRun hooks; GPU/VM irrelevant (hang is pre-window).
• This machine also runs a WFP/WinDivert per-process interceptor (ChatGPT.exe → forced local proxy, no localhost exemption). It does not cause this stall (it was disabled mid-test with no change), but may aggravate child-process spawn latency.

Expected behavior

1. The update-policy wait and shell-env load must not sit on the startup critical path, and must be enforced asynchronously so a slow/hung step can never freeze the whole main process.
2. Runtime re-extraction after an update should show a visible progress state instead of a silent headless window.
3. Failed .staging-* directories should be resumed/cleaned, not re-created from scratch on every launch (12 leftovers ≈ wasted disk).

Related issues (searched before filing)

• #41339 — https://github.com/openai/codex/issues/41339 — closest match: update-policy 300s gate blocks startup on 26.825, identical Failed to load shell env durationMs=337306 timeoutMs=5000 signature
• #41056 — https://github.com/openai/codex/issues/41056 — ~8 min hang before window; repeated .staging-* extraction; unpackaged copy opens in 2.5s
• #41170 — https://github.com/openai/codex/issues/41170 — first-launch ~15 min headless while cua_node runtime extracts
• #41073 — https://github.com/openai/codex/issues/41073 — CODEX_SPARKLE_ENABLED=false workaround report
• #41482 — https://github.com/openai/codex/issues/41482 / #41523 — https://github.com/openai/codex/issues/41523 — same signature on 26.825

Filing separately because this report adds the synchronous-blocking proof (simultaneous timer firing) and staging-directory evidence. Happy to consolidate into #41339 if maintainers prefer.

What steps can reproduce the bug?

1. Microsoft Store auto-updates the OpenAI.Codex MSIX package from 26.820.10647.0 to 26.825.5331.0.
2. Launch the app from the Start menu.
3. Result: multiple ChatGPT.exe background processes appear (all Responding=True, MainWindowHandle=0), but no window ever shows. Windows Event Viewer logs Application Hang 1002.
4. The desktop log freezes permanently at 3 lines (last line: Appshot hotkey inactive configured=true enabled=false platform=win32); no renderer process is spawned; no Crashpad dumps.
5. Killing all ChatGPT.exe processes and relaunching reproduces the hang deterministically (4/4 attempts on 2026-08-29).
6. The hang self-recovers after ~12 minutes: on one launch (started 21:39:01 local) the main process unblocked at 21:50:48 and the window appeared within seconds. Attempts killed before that point looked permanently broken.

Note: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\ accumulates stale .staging-* directories on each failed launch (12 leftovers here; the newest one, e4d75eceaa042f20, was created at the moment of the first failed launch after the update — it is the 26.825 runtime hash).

What is the expected behavior?

No response

Additional information

No response

Start by tracing the startup critical path around the in-app update-policy wait, shell-environment load, and cua_node runtime re-extraction described in the report. Reproduce the Store update launch and inspect the three-line startup freeze, timer behavior, and stale .staging-* directories; done means startup remains responsive, progress is visible, and failed extraction state is handled.