[Windows ARM64] First Codex launch after PC shutdown repeatedly stalls the entire desktop

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

26.721.41059 (About ChatGPT; released 24 Jul 2026). AppX package: 26.721.4979.0 ARM64

What subscription do you have?

ChatGPT Business

What platform is your computer?

Microsoft Windows NT 10.0.26300.0; Windows 11 Home Insider Preview; ARM64; 63.5 GB RAM

What issue are you seeing?

On the first Codex launch after a full PC shutdown, the entire Windows desktop stops responding in several separate bursts. This is not limited to the Codex window: mouse/input and other applications stall too, leaving only short intervals of fluent PC operation between freezes.

I shut the PC down at the end of every day, so this occurs on the first Codex start after the next boot. It also happens again after installing a Codex update and allowing the app to restart.

The problem is improving but is not fixed:

• Previously, an individual whole-PC stall lasted 10 seconds or longer.
• On the current build, individual stalls are usually about 2–3 seconds.
• Multiple stalls still occur during the same startup period.

The current desktop log shows that the visible window becomes ready quickly, while substantial initialization continues afterward:

• Main window ready: 1.947 s after launch.
• Routes mounted: 2.934 s after launch.
• Bundled plugin/marketplace reconciliation: 13.249 s.
• mcpServerStatus/list: 9.390 s.
• app/list: 14.542 s.
• A later focus-triggered reconciliation: 5.607 s.
• Concurrent Git metadata commands across eight configured repositories: 19.433 s combined, with one command taking 8.998 s.

During this period, the Electron process sampler launches system-wide PowerShell/WMI queries using Get-CimInstance Win32_PerfFormattedData_PerfProc_Process and Get-CimInstance Win32_Process, and repeatedly logs failures collecting process snapshots.

There is no Codex crash loop or Windows Error Reporting crash for this session. The symptom is temporary whole-system unresponsiveness while Codex background initialization is running.

What steps can reproduce the bug?

1. Fully shut down a Windows 11 ARM64 PC (not merely close Codex).
2. Start the PC and sign into Windows.
3. Launch Codex for the first time after that boot.
4. Do not interact with Codex; try moving the pointer or using another already-open application.
5. Observe multiple whole-desktop stalls during the Codex startup/background-initialization period. On the current build these are usually 2–3 seconds each, with fluent intervals between them.
6. Let Codex finish initializing; responsiveness then improves.
7. Alternatively, install a Codex application update and allow Codex to restart. The same startup stalls occur again.

What is the expected behavior?

Starting or updating Codex should not make the rest of Windows unresponsive. Background plugin discovery, app/MCP enumeration, repository metadata scans, and process sampling should be delayed, bounded, throttled, cached, or run without monopolizing system resources.

The desktop should remain responsive throughout startup, even if Codex itself is still loading.

Additional information

This is the official native ARM64 package. The installed AppX reports architecture Arm64 and status Ok; the installed Codex runtime is also native ARM64 (PE machine 0xAA64). Therefore, this persists after the earlier x64-emulation problem was fixed.

Historical logs show that bundled-plugin startup reconciliation has improved but was previously much worse: 68.31 s, 55.45 s, and 46.35 s on earlier launches, compared with 13.249 s on the current build.

Possibly related existing reports:

• #22912 — Windows desktop freezes while the Electron sampler fails WMI process snapshots.
• #33483 — Windows desktop freezes after migration to the new ChatGPT app.

This report adds a deterministic trigger (first launch after a full shutdown, or launch after an update), current native-ARM64 build information, and measured initialization timings.

Personal paths, repository names, and conversation contents have been omitted. The separate false-update indication and older-task loading behavior are intentionally excluded from this report.

Why GitHub's three suggested issues do not appear to be duplicates

• #35215: Codex launches once, then fails to relaunch in the same Windows session with AppModel error 0x800701C0. In this report Codex launches successfully; the problem is repeated whole-desktop stalls during its initialization, with no launch failure or that error code.
• #34305: An x64 build becomes permanently unresponsive after Electron memory rises from about 868 MB to 2.56 GB, producing Windows Event ID 1002 / MoAppHang before Windows closes the application. This report concerns a native ARM64 build, has no observed memory spike, AppHang, crash, or forced termination, and responsiveness returns when startup initialization settles.
• #34292: That ARM64 report describes freezes during normal use and thread switching, experimentally isolated to synchronous Codex Micro HID discovery; patching out the HID call removed the problem. This report has a deterministic cold-start/update trigger. Current logs contain no Codex Micro/HID discovery indication and instead correlate the stall window with bundled-plugin reconciliation, failed system-wide PowerShell/WMI process sampling, and long app/MCP/Git operations. HID discovery cannot be ruled out solely from the absence of a log entry, but the trigger and available diagnostic evidence are different.