Windows app repeatedly freezes on launch while synchronously hashing bundled executables on the main thread

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

26.707.31428

What subscription do you have?

Plus

What platform is your computer?

Windows 11 25H2

What issue are you seeing?

Every time I launch the Windows Codex app, the UI repeatedly freezes for roughly the first 30 seconds before becoming usable. The freezes occur in bursts of about 0.6–1.4 seconds.

A 32-second Chromium performance trace attributes the stalls to synchronous relocation validation of executables bundled under C:\Program Files\WindowsApps. Codex repeatedly reads and SHA-256 hashes the bundled source files and their cached copies on CrBrowserMain.

The sampled stack is:

mcp-codex-config → buildMcpCodexConfig → runtime path resolution → wM → _M → NM → PM/LM → RM → fs.readFileSync → crypto.createHash("sha256").update(...)

The bundled executable set being validated is approximately 405 MB (codex.exe is 341 MB, plus code-mode, sandbox, and command-runner helpers). A successful validation hashes both source and cached destination, roughly 810 MB per resolver invocation. The resolver is invoked repeatedly during startup and MCP/browser configuration.

Trace totals:

• 8.4 seconds inside synchronous bundled-executable hashing on the browser/main thread
• 30 main-thread microtasks longer than 100 ms, totaling 12.2 seconds
• At least 11 major hash-related blocking bursts
• Another 1.63 seconds comparing relocated Node/runtime files
• Renderer idle for 28.1 of the 32 captured seconds

This appears deterministic in the Windows Store/MSIX build and is not project-specific.

What steps can reproduce the bug?

1. Install/open the Codex Windows Store app.
2. Enable normal Codex features/plugins. Browser/Chrome control are enabled in my setup.
3. Fully close the app.
4. Launch Codex again.
5. Try to interact with or move the window during the first ~30 seconds.

Result: the app repeatedly stops responding in 0.6–1.4 second bursts before eventually becoming usable.

I reproduce this on every launch. I captured a performance trace using Help → Start Performance Trace and stopped it during the freeze period.

What is the expected behavior?

Codex should become responsive immediately after the window appears.

Relocated runtime validation should be cached per app version/process or performed off the browser/main UI thread. Starting the app should not repeatedly read and hash hundreds of megabytes of bundled and cached executables.

Additional information

The renderer is not the bottleneck: it was idle for 28.1 of the 32 captured seconds. GPU, layout, Git, and network activity do not account for the freezes. One ~1.0 second renderer pause in the trace is caused by starting the CPU profiler itself and is unrelated.

The blocking implementation path appears to validate WindowsApps relocation by hashing both source and destination on every resolver call, with no process-level memoization. mcp-codex-config alone accounts for two ~1.2 second stalls in the capture.

Suggested fix: memoize relocation validation for the current app/runtime version, use file metadata/version stamps where safe, and move any full-file hashing off CrBrowserMain.

I retained the 383 MB trace locally and can provide it if needed.