Repository navigation
[Bug] Windows Desktop 26.715.4045 freezes during bundled-plugin reconcile; plugin/list blocks for ~61s #34244
Description
Summary
Codex Desktop on Windows repeatedly becomes unresponsive after startup and during sidebar use. The fresh logs point to the Desktop bundled-plugin reconciliation path rather than a damaged thread or a slow plugin index: plugin/list and app/list block for about 61 seconds while the generated openai-bundled marketplace alternates between five and six plugins, removes browser, then reinstalls it as missing, and reinstalls chrome as outdated.
Environment
- Windows 11 Home 25H2, build 26200.8875, x64
- Microsoft Store package:
OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0 ChatGPT.exe: 150.0.7871.124- Desktop release reported in log: 26.715.31925
- Global CLI: 0.144.6
Observed behavior
- The window intermittently reports
Responding=Falseafter startup/sidebar interaction. - Main-process RSS temporarily rose from about 419 MB to about 1.07 GB during one occurrence, then later returned to about 290 MB.
- The same installation frequently becomes usable again after the ~60-second block, then freezes again later.
- Repair/reset/reinstall and archiving the previously suspected large thread did not eliminate the issue.
Relevant sanitized fresh-log events:
2026-07-19T15:02:45.085Z [AppServerConnection] method=plugin/list durationMs=60878 errorCode=null
2026-07-19T15:02:45.302Z [AppServerConnection] method=app/list durationMs=61274 errorCode=null
2026-07-19T15:02:46.950Z [BundledPluginsMarketplace] pluginCountAfterWrite=5 pluginCountBeforeWrite=6 pluginNames=[sites,chrome,computer-use,latex,visualize]
2026-07-19T15:02:50.438Z [BundledPluginsMarketplace] pluginName=chrome reason=outdated
2026-07-19T15:02:52.575Z [BundledPluginsMarketplace] pluginName=browser reason=not_in_bundled_marketplace_plugin_names
2026-07-19T15:03:55.219Z [BundledPluginsMarketplace] plugin_marketplace_folder_write_failed folderWritePhase=stop_chrome_native_host pluginCountAfterWrite=6 pluginCountBeforeWrite=5
2026-07-19T15:03:58.286Z [BundledPluginsMarketplace] pluginCountAfterWrite=6 pluginCountBeforeWrite=5 pluginNames=[sites,browser,chrome,computer-use,latex,visualize]
2026-07-19T15:03:59.894Z [BundledPluginsMarketplace] pluginName=browser reason=missing
2026-07-19T15:04:01.870Z [BundledPluginsMarketplace] pluginName=chrome reason=outdated
2026-07-19T15:05:05.535Z [AppServerConnection] method=plugin/list durationMs=60885 errorCode=null
The same interval also reports an electron child-process sampler failure for a spawned PowerShell command that queries Win32_PerfFormattedData_PerfProc_Process and Win32_Process. That sampler error is then surfaced in BundledPluginsMarketplace failures.
Control tests
The equivalent operations complete normally outside the Desktop orchestration:
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process: 917 msGet-CimInstance Win32_Process: 75 msWin32_Processwith the same PIDORfilter: 175 ms- Desktop-bundled
codex.exe plugin list: 91 ms
This makes a WMI failure or inherently slow plugin index unlikely. The evidence instead suggests a Desktop child-process result-routing, synchronization, or bundled-plugin reconciliation regression.
Session-state checks
After archiving the originally suspected large thread and restarting:
- sidebar
.slice()TypeError: 0 Item not found in turn state: 0ResizeObserver loop: 0- archived-thread auto-resume: 0
thread_count_streaming_without_active_runtime: 0inflight_turn_count: 0
The unresponsive behavior continued despite those values being clean.
Expected behavior
plugin/listandapp/listshould not block the Desktop UI for ~61 seconds.- The runtime-generated bundled marketplace should not alternate between five and six entries during one startup.
browsershould not be removed and immediately reinstalled as missing.- A child-process sampler failure should not stall or contaminate bundled marketplace reconciliation.
Related reports
- [Bug] Windows Codex Desktop intermittently freezes with desktop-notifications DLL failure (0xc06d007f) #33488 — current Windows Desktop intermittent freeze on a recent package
- Windows Desktop 26.601: global CLI and Desktop bundled-plugin reconcile can fight over shared config.toml #26366 — Desktop bundled-plugin reconcile/shared marketplace state
- Codex App fails to register that it's loading with the Windows system #21603 — Windows app shows Not Responding when clicked during startup
Raw session JSONL, Sentry scope, account identifiers, and user paths are intentionally not attached. A redacted support bundle is available if maintainers request it.
Activity
github-actions commentedon Jul 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
B1umenkrAn2 commentedon Jul 20, 2026
Codex Desktop version: 26.715.4045.0
Device: HyperX Cloud III USB headset
OS: Windows 11
Issue:
Codex Desktop freezes when ChatGPT has microphone permission and the HyperX Cloud III headset is connected through USB. Windows eventually reports “Codex is not responding.”
Reproduction steps:
Workaround verification:
This suggests the freeze is triggered when ChatGPT/Codex attempts to access or initialize the HyperX Cloud III USB microphone.
aidawilliam41-ops commentedon Jul 22, 2026
Independent recurrence and root-cause evidence on a newer Windows build
Environment:
26.715.10079.00.145.0-alpha.30codex.exeSHA-256:ADF966822B9A04FB3A6E41D7D6A44B60E5C87BEAC6AEBEF5C0B0A2205C8CDF62A clean exact-tree Desktop restart independently reproduced the same bundled-marketplace oscillation:
The previous Desktop process tree was confirmed absent before relaunch. The observer performed filesystem/process reads only and did not call Codex APIs or write plugin/config state.
A separate logged startup on the same installed version preserved the causal ordering:
browserPane=falsebrowserPane=trueRead-only inspection of this exact installed
app.asarshows the matching mechanism:The causal run had the expected Desktop-owned marketplace source and successful add/write records. It contained no source-conflict, access-denied, file-lock, or write-failed event. This isolates the startup reconcile race from the WMI/sampler failure observed in the original report: that failure may worsen latency, but it is not required for the
6 → 5 → 6transition.Confirmed impact:
ENOENTwarnings in an earlier occurrenceThe exact share of user-visible stutter attributable to this path remains unknown because task restoration and other startup work occur concurrently. The clean restart's exact writer PID is also unavailable because the live Desktop log had not flushed during that observation; its identical transition is supporting recurrence evidence, while the logged runs establish the mechanism.
Minimal product-side fix:
Acceptance should require one clean startup with no
6 → 5 → 6, no Browser uninstall/reinstall, and no missing Browser asset warnings.No local usernames, absolute paths, account data, credentials, private logs, or task content are included.
levgoriachev commentedon Jul 24, 2026
Current-build ETW evidence: two startup reconciles and full marketplace rewrites
This remains reproducible on the current Microsoft Store package:
OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0CODEX_HOMEThe isolated run produced no
taskkill.exeprocesses, but Desktop still reached approximately 2.58 GiB working set in about 30 seconds with heavy disk activity. This isolates the bundled-plugin path from conversation restoration and the separate cleanup/WMI storm.The Desktop log shows two serialized startup reconciles:
Read-only inspection of this exact build's
app.asarmatches the observed behavior:fs.cp.A Windows ETW file-I/O trace of the clean isolated launch attributed, among other activity:
tectonic.exe;The packaged bundled marketplace is only about 64 MiB, so the measured traffic is consistent with redundant materialization plus plugin catalog refresh. No staging directories accumulated after exit; this is repeated work, not the separate stale-staging leak.
Disabling all plugins in the isolated config did not provide a stable workaround: Desktop restored/reinstalled bundled plugin state, and memory remained around 2.5 GiB. Therefore deleting chats, disabling individual plugins, or clearing the cache does not address the startup race.
Suggested product-side fixes:
Acceptance should include one cold launch with no second marketplace write, no plugin uninstall/reinstall oscillation, and bounded physical I/O after the marketplace is already valid.
No usernames, absolute user paths, credentials, task contents, or raw ETW/log files are included.
zemeng5208 commentedon Aug 12, 2026
Disclosure: I maintain WinBridge Recovery, a non-official Windows recovery/diagnostic utility for Codex Desktop.
The repeated marketplace transition in this report — generated
openai-bundledcontents changing,browserbeing removed asnot_in_bundled_marketplace_plugin_names, then reinstalled as missing while Chrome is outdated — overlaps with the state-consistency checks the project performs.WinBridge Recovery compares the current installed Codex package with the user-side bundled marketplace and versioned plugin cache, validates active pointers/registrations, and can rebuild inconsistent local state after creating a rollback backup. That may help when repeated reconciliation is being amplified by an incomplete/stale marketplace or cache left from an earlier update.
I would not claim it fixes the ~61 s Desktop orchestration/child-process stall itself. If the marketplace/cache is already complete and the freeze is caused purely by the app's WMI/result-routing synchronization, that remains an upstream bug. The utility is useful here mainly to eliminate or repair the persistent local-state inconsistency so the remaining timing issue can be isolated more cleanly.
Triadus commentedon Aug 14, 2026
Independent recurrence: missing optional PerfProc class aborts Chrome native-host reinstall
Environment:
26.810.4967.0151.0.7922.1381.2.27259.19709_026.623.141536Observed sequence:
Defaultprofile, and Chrome is running.HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextensionregistration are absent. Codex's native-host state file has no entries.Fresh Desktop logs repeatedly show:
The nested command fails here:
Get-CimInstance Win32_PerfFormattedData_PerfProc_Processwith:
Win32_Processremains available. Only the three abstract/base performance classes are present; the concreteWin32_PerfFormattedData_*andWin32_PerfRawData_*classes are unavailable. Reboot pluslodctr /R,winmgmt /resyncperf, andwmiadap /fdid not change that state.The important product behavior is that an optional CPU/process-sampling dependency aborts bundled-plugin reconciliation/native-host lifecycle. Even if the performance-counter class is unavailable, Codex should still be able to stop/install the Chrome native host by falling back to
Win32_Processwithout CPU fields, another process-enumeration API, or an empty CPU map. A telemetry failure should not leave the official Chrome extension installed but permanently disconnected.Impact: authenticated local Chrome QA is blocked; only the in-app browser backend remains available.
No usernames, absolute user paths, account identifiers, private URLs, credentials, or task contents are included.
James-Yin718 commentedon Aug 19, 2026
I can reproduce what appears to be the same failure on a newer Windows desktop build, with a more specific UI trigger.
Environment
OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0ChatGPT.exe:151.0.7922.137Reproduction pattern
This occurred three times on 2026-08-19. Windows Error Reporting recorded
AppHangTransientfor the same executable/version at 08:43:00, 08:56:35, and 09:54:06 local time.Correlated evidence from the latest occurrence
AppHangTransientforChatGPT.exe 151.0.7922.137..codex-remote-plugin-install.jsonmarkers were rewritten at the same time for several bundled/remote plugins (including GitHub, Canva, templates, and plugin management).main_thread_jank_snapshot, multi-secondplugin/listcalls, and historicalplugin_marketplace_folder_write_failedevents in phasestop_chrome_native_host, with spawned PowerShell/CIM queries overWin32_PerfFormattedData_PerfProc_ProcessandWin32_Process.A direct cold control run of
Get-CimInstance Win32_PerfFormattedData_PerfProc_Processtook 7.6 seconds on this machine; immediate repeats took roughly 0.4–0.6 seconds. An earlier cold combined query exceeded 30 seconds, while later warm runs completed around one second.CPU, RAM, disk, and GPU were not exhausted, and this occurs before any model request is sent. The timing therefore looks consistent with a periodic bundled-plugin refresh / child-process sampling path being initiated by the first + menu open after the cache becomes cold. The exact blocking thread would still require a hang dump to prove, but the correlation is strong.
Expected behavior
Opening + should remain responsive even when plugin metadata is stale. Plugin reconciliation, native-host shutdown, and WMI/process sampling should be asynchronous, cached, and bounded by short timeouts/backoff.
I intentionally omitted raw session files, prompts, account identifiers, user paths, and credentials. I can provide additional sanitized log lines or a hang dump if maintainers specify what is needed.
qqqzhH commentedon Sep 10, 2026
Cross-reference: we captured the same class of freeze on
26.901.6511.0with main-thread evidence — the Desktop main process blocks inWait, EventPairLow(synchronous IPC) for 3–26 s, ~1.5 times per minute, with ~+300 MB RSS at stall start and no other process consuming CPU/GPU at the time.Full measurements (thread-state distribution, per-process CPU at t0/t+3 s, and a long ruled-out list: Responses WebSocket, remote-control WebSocket, in-app browser, MCP/plugins, HID enumeration, AV kernel drivers, disk, large threads, DWM, WMI):
One difference from this report worth noting: on our machine
plugin/listandmcpServerStatus/listonly block for 2–5 s once at startup, while the recurring stalls happen afterwards with a completely empty log window (no plugin/marketplace event in the 10 s before each stall). So the recurring stalls here do not look like they are driven by the bundled-plugin reconcile path described above — though the main-process RSS signature (419 MB -> 1.07 GB here, +300 MB there) is strikingly similar.