[App] Windows 26.908.3777.0: ~50% of launches die at startup — "Initial route prefetch failed: r is not a function", then the error boundary takes down the whole UI with no recovery

Summary

On Windows, the ChatGPT/Codex desktop app 26.908.3777.0 fails to start roughly half the time. The window opens and immediately shows "ChatGPT hit a snag — Something went wrong. Try again to continue". Try again reproduces it; Update ChatGPT reports "ChatGPT is up to date". Relaunching eventually succeeds — it is effectively a coin toss.

Measured across 12 consecutive launches on one machine: 5 failed, 7 succeeded, with no configuration change between them.

I'm deliberately reporting the observable signature rather than proposing a mechanism — I don't have enough to say why the prefetch fails.

Failure signature

Failing launches log this, and succeeding launches never do:

warn  [electron-message-handler] Initial route prefetch failed; rendering will retry
      errorMessage="r is not a function" errorName=Error errorStack="Error: r is not a function"
      route=primary rendererWindowVisible=true windowType=electron

~2 s later the exception surfaces inside the root render and React's error boundary swallows the entire tree:

error [electron-message-handler] error boundary
componentStack="\n    at Lazy (<anonymous>)\n    at Suspense (<anonymous>)
    at fm (app://-/assets/app-initial-5efcb2fc7e21.js:1722:140114)
    at Nos (app://-/assets/app-initial-5efcb2fc7e21.js:8082:55588) ..."

The warning says "rendering will retry", but in the failing launches no recovery happens — the UI stays dead until the process is restarted. Whatever the retry path is meant to do, it doesn't save it.

What separates a failing launch from a working one

Timings are ms from process start.

Failing — 5/5 identical shape:

+1,014   window ready-to-show              x1
+1,023   window main frame finished load   x1
+1,516   React root render requested       x1
+1,516   Initial route prefetch FAILED     "r is not a function"
+3,961   error boundary  ->  UI dead, no further activity

Working — 7/7 identical shape:

+1,032 / +7,019 / +10,019   window ready-to-show             x3
+1,048 / +7,053 / +10,047   window main frame finished load  x3
+1,590 / +10,411            React root render requested      x2
                            no prefetch failure at all

So the cleanest discriminator is simply: prefetch failure present → one load cycle then death; prefetch failure absent → three load cycles, two renders, working app.

The prefetch warning and the "React root render requested" line carry the same millisecond in all five failures (+1516/+1516, +1568/+1567, +1633/+1633, +1605/+1604, +1476/+1476). Both are emitted by [electron-message-handler], so this may just be two adjacent log calls rather than anything meaningful — noting it in case the ordering is useful to you, not offering it as a diagnosis.

The bundled-plugin path is NOT involved

Stating this explicitly because it looks related and isn't:

event	time from start
initial route prefetch failure	+1.5 s
bundled_plugins_reconcile_started	+3.1 – 5.5 s
bundled_plugins_marketplace_added	+4.3 – 7.6 s
plugin `sites` was not found in marketplace	+4.9 – 9.0 s

All of it runs after the UI has already died, and the sites failure occurs identically in all seven working launches. (That sites failure is a separate, pre-existing bug — filing separately.)

Regression window

Zero occurrences of Initial route prefetch failed / r is not a function across ~6 days of retained desktop logs before 26.908.3777.0 was registered at 2026-09-11 15:26 local. Present from the very first launch afterwards, and on roughly half of all launches since.

Environment

• MSIX package: OpenAI.Codex 26.908.3777.0 (OpenAI.Codex_26.908.3777.0_x64__2p2nqsd0c76g0), Status: Ok
• App version reported internally: 26.908.31457
• Chromium: 152.0.7977.83
• Windows 11 Home 25H2, 10.0.26200.8894, x64
• Ryzen 9 9950X / 64 GB / RTX 5090

Logs: %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\

Ruled out locally — none of these changed the outcome

• MSIX package state: Status: Ok; staged plugin files verified byte-identical to those shipped in the package
• A completely virgin Electron profile
• Removing ~/.codex entirely
• Removing / rebuilding .tmp/bundled-marketplaces, and deleting .materialization-key (the regenerated key is byte-identical to the old one)
• Disabling the sites plugin and removing the bundled marketplace from config.toml entirely — still fails
• UAC, AppXSvc, ClipSVC, StateRepository, TokenBroker, luafv — all healthy
• No crash dumps: Crashpad database empty, no Application Error / Hang / .NET Runtime events. This is a JS-layer fault, not a process crash.

Caveat on the above: because the failure is ~50% intermittent, single-launch testing is unreliable. Each of these was observed over multiple launches, but I'd treat them as strong indications rather than proof.

Expected behaviour

A failure in the initial route prefetch should not be able to take down the entire React tree. Either the advertised retry should actually recover it, or the prefetch should fail soft and let the app render.

Happy to help

I can reproduce this readily and can capture whatever would help — full desktop logs, a trace, or repeated-launch statistics.

Start with the [electron-message-handler] initial route prefetch and root render/error-boundary events described in the issue, using the desktop logs under %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs. Reproduce repeated Windows launches and compare failing and working sequences. Done means an initial prefetch failure either recovers through the advertised retry or leaves the app able to render instead of taking down the entire UI.