›_ Codex Issues
Codex Issues / #34244

[Bug] Windows Desktop 26.715.4045 freezes during bundled-plugin reconcile; plugin/list blocks for ~61s

Open 💬 7 comments Opened Jul 19, 2026 by sukonbu212
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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=False after 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 ms
  • Get-CimInstance Win32_Process: 75 ms
  • Win32_Process with the same PID OR filter: 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: 0
  • ResizeObserver loop: 0
  • archived-thread auto-resume: 0
  • thread_count_streaming_without_active_runtime: 0
  • inflight_turn_count: 0

The unresponsive behavior continued despite those values being clean.

Expected behavior

  • plugin/list and app/list should not block the Desktop UI for ~61 seconds.
  • The runtime-generated bundled marketplace should not alternate between five and six entries during one startup.
  • browser should not be removed and immediately reinstalled as missing.
  • A child-process sampler failure should not stall or contaminate bundled marketplace reconciliation.

Related reports

  • #33488 — current Windows Desktop intermittent freeze on a recent package
  • #26366 — Desktop bundled-plugin reconcile/shared marketplace state
  • #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.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #34117
  • #34069
  • #34025

Powered by Codex Action

B1umenkrAn2 · 1 month ago

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:

  1. Enable microphone permission for ChatGPT in Windows Settings.
  2. Connect the HyperX Cloud III headset through USB.
  3. Open Codex Desktop.
  4. Codex freezes and becomes unresponsive.
  5. While Codex is frozen, unplug the headset USB connection.
  6. Codex immediately recovers and becomes responsive again.

Workaround verification:

  1. Close Codex Desktop.
  2. Disable microphone permission for ChatGPT in Windows Settings.
  3. Reconnect the HyperX Cloud III headset through USB.
  4. Open Codex Desktop.
  5. Codex no longer freezes and works normally while the headset remains connected.

This suggests the freeze is triggered when ChatGPT/Codex attempts to access or initialize the HyperX Cloud III USB microphone.

aidawilliam41-ops · 1 month ago

Independent recurrence and root-cause evidence on a newer Windows build

Environment:

  • Codex Desktop: 26.715.10079.0
  • bundled CLI/app-server: 0.145.0-alpha.30
  • codex.exe SHA-256: ADF966822B9A04FB3A6E41D7D6A44B60E5C87BEAC6AEBEF5C0B0A2205C8CDF62
  • Windows 11 x64

A clean exact-tree Desktop restart independently reproduced the same bundled-marketplace oscillation:

  • +0.035 s: 6 plugins; Browser assets present
  • +22.399 s: 5 plugins; Browser and both Browser assets absent
  • +46.526 s: 6 plugins; Browser and both assets restored

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:

  • 14:40:18.458: bundled-plugin reconcile started
  • 14:40:18.460: renderer reported Browser unavailable / browserPane=false
  • 14:40:18.473: renderer reported Browser available / browserPane=true
  • 14:40:31.172: Desktop wrote the stale five-plugin marketplace
  • 14:40:46.748: that reconcile completed and an already queued reconcile began
  • 14:40:49.574: Desktop restored the six-plugin marketplace

Read-only inspection of this exact installed app.asar shows the matching mechanism:

  1. Browser feature-availability changes invoke the bundled-plugin reconcile scheduler.
  2. Each call captures the feature state and is serialized behind the pending reconcile promise.
  3. A queued job whose captured state is already stale is not coalesced or cancelled before writing.
  4. The write path replaces the generated runtime marketplace and uninstalls enabled plugins absent from that captured list.

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 → 6 transition.

Confirmed impact:

  • transient Browser removal and feature unavailability
  • redundant uninstall/install/list work
  • two missing-asset ENOENT warnings in an earlier occurrence
  • approximately 28–36 seconds before the stale reconcile was corrected

The 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:

  • coalesce or drop a queued reconcile when its captured feature-state key is no longer current; or
  • defer the initial bundled-plugin reconcile until feature hydration stabilizes.

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.

lev-goryachev · 1 month ago

Current-build ETW evidence: two startup reconciles and full marketplace rewrites

This remains reproducible on the current Microsoft Store package:

  • Codex Desktop package: OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0
  • Windows x64
  • clean isolated CODEX_HOME
  • no sessions, saved projects, authentication, or user task activity

The isolated run produced no taskkill.exe processes, 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:

11:05:58.062  first bundled reconcile started
11:06:01.252  runtime marketplace written
11:06:16.085  first reconcile completed; queued reconcile started
11:06:17.982  runtime marketplace written again

Read-only inspection of this exact build's app.asar matches the observed behavior:

  1. The materialization key includes app/bundle versions plus Browser skill, Computer Use skill, and Live Visualization variants.
  2. Reuse requires an exact key and manifest match.
  3. A key miss builds a staging marketplace and copies every selected bundled plugin concurrently with fs.cp.
  4. Startup begins with default feature availability, then renderer/remote feature hydration changes the effective variants and queues another reconcile.
  5. The queued reconcile is serialized but is not coalesced or dropped when its captured state becomes stale/current during startup.

A Windows ETW file-I/O trace of the clean isolated launch attributed, among other activity:

  • approximately 94.7 MiB physical reads from the packaged LaTeX tectonic.exe;
  • approximately 47.3 MiB writes to the isolated bundled-marketplace staging copy;
  • approximately 20.5 MiB writes to a temporary plugin-catalog Git pack.

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:

  • defer the initial reconcile until feature availability is hydrated;
  • coalesce queued reconciles by the latest materialization key and drop stale captures before writing;
  • avoid copying the full marketplace when only a feature-dependent manifest/skill variant changed;
  • cache the plugin catalog clone/pack across launches;
  • add a regression test requiring exactly one marketplace materialization on a clean Windows launch.

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 · 16 days ago

Disclosure: I maintain WinBridge Recovery, a non-official Windows recovery/diagnostic utility for Codex Desktop.

The repeated marketplace transition in this report — generated openai-bundled contents changing, browser being removed as not_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 · 13 days ago

Independent recurrence: missing optional PerfProc class aborts Chrome native-host reinstall

Environment:

  • Windows 11 x64
  • Codex Desktop Microsoft Store package: 26.810.4967.0
  • Google Chrome: 151.0.7922.138
  • Codex Chrome Extension: 1.2.27259.19709_0
  • bundled Browser/Chrome plugin cache: 26.623.141536

Observed sequence:

  1. The Chrome connector had previously worked and Codex could enumerate and claim authenticated local Chrome tabs.
  2. The Chrome plugin and extension were removed/reinstalled through the official UI.
  3. The extension is now installed and enabled in the selected Default profile, and Chrome is running.
  4. The native-host manifest and HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension registration are absent. Codex's native-host state file has no entries.
  5. Browser runtime bootstrap succeeds and the in-app browser is discoverable, but no Chrome-extension browser backend is registered.

Fresh Desktop logs repeatedly show:

[BundledPluginsMarketplace] plugin_marketplace_folder_write_failed
folderWritePhase=stop_chrome_native_host

The nested command fails here:

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process

with:

HRESULT 0x80041010 / Invalid class

Win32_Process remains available. Only the three abstract/base performance classes are present; the concrete Win32_PerfFormattedData_* and Win32_PerfRawData_* classes are unavailable. Reboot plus lodctr /R, winmgmt /resyncperf, and wmiadap /f did 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_Process without 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 · 9 days ago

I can reproduce what appears to be the same failure on a newer Windows desktop build, with a more specific UI trigger.

Environment

  • Windows x64
  • Microsoft Store package: OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0
  • ChatGPT.exe: 151.0.7922.137
  • About 32 GB RAM; about 16.9 GB was free during the latest hang
  • The legacy ChatGPT Classic app was not running
  • The ChatGPT for Chrome extension was not connected/enabled

Reproduction pattern

  1. Leave the desktop app open long enough for the bundled-plugin cache/refresh interval to expire (approximately one hour in my observations).
  2. Click the + button in the composer to open the files/projects/goals/plugins menu.
  3. The whole window can stop responding and Windows displays the white/ghosted window.
  4. After the app recovers, reopening + is much faster.
  5. After another idle interval, the slow/hanging first open can recur.

This occurred three times on 2026-08-19. Windows Error Reporting recorded AppHangTransient for the same executable/version at 08:43:00, 08:56:35, and 09:54:06 local time.

Correlated evidence from the latest occurrence

  • 09:53:26: WMI Activity events reported cancelled/throttled queries involving process/performance providers.
  • 09:54:06: WER recorded AppHangTransient for ChatGPT.exe 151.0.7922.137.
  • 09:54:48: the generated .codex-remote-plugin-install.json markers were rewritten at the same time for several bundled/remote plugins (including GitHub, Canva, templates, and plugin management).
  • The previous marker refresh was around 08:55:10, about 59 minutes 38 seconds earlier.
  • Desktop logs contain main_thread_jank_snapshot, multi-second plugin/list calls, and historical plugin_marketplace_folder_write_failed events in phase stop_chrome_native_host, with spawned PowerShell/CIM queries over Win32_PerfFormattedData_PerfProc_Process and Win32_Process.

A direct cold control run of Get-CimInstance Win32_PerfFormattedData_PerfProc_Process took 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.