Windows Codex app still micro-freezes after prompts in build 26.601.2237.0

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

• #25094
• #25390
• #25709
• #25506

Powered by Codex Action

Thanks. I reviewed the suggested duplicates.

This issue is related to #25094, #25390, #25709, and #25506, but I do not
think it should be closed yet because it adds newer build data and
additional mitigation results.

Additional differences/details:

• Reproduced on OpenAI.Codex 26.601.2237.0.
• Defender sample submission/exclusions reduced the severity but did not

eliminate the freezes.

• Launching Codex with GPU disabled did not resolve the remaining

micro-freezes.

• Clearing .codex-global-state.json reduced state size temporarily, but

Codex rebuilt it on launch.

• Logs still showed Browser/IAB/Computer Use initialization attempts even

after related plugins/config were disabled.

So this may be the same underlying Windows Desktop performance/regression
family, but this report adds newer evidence and mitigation results.

Em qui., 4 de jun. de 2026 às 11:52, github-actions[bot] <
@.***> escreveu:

github-actions[bot] left a comment (openai/codex#26401) <https://github.com/openai/codex/issues/26401#issuecomment-4623286012> Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #25094 <https://github.com/openai/codex/issues/25094> - #25390 <https://github.com/openai/codex/issues/25390> - #25709 <https://github.com/openai/codex/issues/25709> - #25506 <https://github.com/openai/codex/issues/25506> Powered by Codex Action <https://github.com/openai/codex-action> — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/26401?email_source=notifications&email_token=BVVK2D5J2DFAWZWOLOIWERL46GEJJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRSGMZDQNRQGEZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4623286012>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVVK2D6QWYDWZCOO4MBR5MD46GEJJAVCNFSM6AAAAACZ2PTZUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMMRTGI4DMMBRGI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BVVK2D3SLPZ6BQM2W6ZGY6T46GEJJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRSGMZDQNRQGEZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/BVVK2D4KVBVZZSHHUY7MFQD46GEJJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRSGMZDQNRQGEZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: @.***>

Additional update, 2026-06-06:

The issue is still present after an automatic update to:

• OpenAI.Codex 26.602.4764.0
• PackageFullName: OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0

New observation: Codex can freeze even when no user request is actively processing.

Windows logged a new event:

• 2026-06-06 10:33:56 local time: AppHangTransient
• P1: Codex.exe
• P2: 149.0.7827.54
• Report ID: a772688e-3450-4535-9542-7ae0347a58f7

New relevant log patterns from the 26.602.4764.0 build:

• Dropping invalid desktop setting key=conversationDetailMode
• BundledPluginsMarketplace ... bundled_plugin_reinstall_uninstall_requested ... pluginId=chrome@openai-bundled ... reason=forced
• bundled_plugins_marketplace_install_failed ... plugin_cache_windows_file_lock ... Acesso negado. (os error 5)
• bundled_plugins_reconcile_failed ... reason=startup
• bundled_plugins_reconcile_started ... reason=focus
• browser_use_availability_resolved available=true browserPane=true platform=Windows
• repeated computer-use native pipe startup failed / Windows Computer Use helper paths are unavailable

There was also another Codex-related process running from the Cursor extension:

• .cursor\extensions\openai.chatgpt-26.601.20914-win32-x64\bin\windows-x86_64\codex.exe app-server --analytics-default-enabled

This may or may not be related, but it is worth noting because the desktop app logs now show plugin cache/file-lock failures while reconciling bundled plugins.

This strengthens the hypothesis that the remaining freezes are not tied only to active model responses, but may also be related to background plugin reconciliation, Browser/IAB/Computer Use startup paths, or app-server/UI background work in the Windows desktop app.

Additional update, 2026-06-06:

I found a more concrete cause for one of the background freezes/cache failures.

The bundled Chrome plugin cache was locked by:

• extension-host.exe
• Path: .codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

chrome\latest was a junction pointing to:

• .codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome

Using Windows Restart Manager, the locking process was reported as:

• Process: extension-host
• ApplicationType: RmConsole
• Path: .codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

This explains the earlier startup/focus log errors:

• bundled_plugin_reinstall_uninstall_requested ... pluginId=chrome@openai-bundled ... reason=forced
• bundled_plugins_marketplace_install_failed ... plugin_cache_windows_file_lock ... Acesso negado. (os error 5)

After renaming the bundled plugin cache, Codex/Chrome recreated the cache and relaunched extension-host.exe almost immediately.

I then found the Chrome Native Messaging host:

• Registry key: HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
• Manifest: C:\Users\Igor\AppData\Local\OpenAI\extension\com.openai.codexextension.json

As a local test, I backed up/renamed that registry key to:

• com.openai.codexextension.disabled

Then I stopped the current cmd.exe / extension-host.exe processes launched from the Codex Chrome plugin cache. They did not immediately respawn after the Native Messaging host was disabled.

This suggests that the Chrome extension/native messaging path can keep extension-host.exe alive and lock the bundled Chrome plugin cache, while the desktop app simultaneously tries to reconcile/reinstall bundled plugins on startup/focus. That appears to contribute to freezes even when no model request is actively running.

Just wanted to say I've also been having severe performance issues with the Codex app on Windows 11 Pro. It has gotten to the point where it seems to be causing my entire PC to stutter every singe time it sends a message or runs a command, and I've been trying every possible thing I can think of from GPU drivers to reinstalls but nothing seems to help. Starting the app alone causes my inputs to just lock up and lag for a few seconds without even doing anything else. Dunno what it's doing but whatever it is it's extremely heavy on my system for some reason.

I'm running on a Ryzen 9 9950X3D, 96GB RAM, and an RTX 5080, so I don't think there should be anything wrong with my computer's specs that would cause this.

<html>
<body>
<!--StartFragment--><html><head></head><body>
<p><strong>Windows: <code>@</code> mention picker hangs the app for 86-107s; isolated to the Computer Use bundled plugin (native pipe/helper startup failure blocking app-server)</strong></p>
<h2>Environment</h2>
<ul>
<li>Codex Windows package <code>26.715.7063.0_x64</code> (app version <code>26.715.52143</code>), bundled CLI <code>codex-cli 0.145.0-alpha.18</code></li>
<li>Windows 10 Pro 19045, x64, i7-7700HQ, 24 GB RAM</li>
<li>Native Windows agent mode (no WSL); <code>integratedTerminalShell</code> not set to wsl</li>
<li>Also reproduced on the earlier package build <code>26.715.4045.0</code></li>
</ul>
<h2>Symptom</h2>
<p>Typing <code>@</code> in the composer within roughly the first 1-2 minutes after launch freezes the entire app ("Codex is not responding"). Windows Application log records genuine hangs (<code>AppHangTransient</code> / <code>MoAppHang</code> for <code>ChatGPT.exe</code>), 7 events in one evening. Each freeze lasts 86-107 seconds, then the UI recovers and delayed timers/network callbacks fire together. Renderer breadcrumbs stop entirely during the hang.</p>
<p>Renderer log signature around each freeze:</p>
<pre><code>ui.input div.ProseMirror.ProseMirror-focused
[AppServerConnection] response_orphaned requestId=app/list:&lt;uuid&gt; transportKind=stdio
[electron-message-handler] No promise for request ID id=app/list:&lt;uuid&gt;
[~107s of no renderer breadcrumbs]
[bundled-plugins] bundled_plugins_reconcile_failed
errorMessage="Timed out waiting for MCP response to config/batchWrite" reason=startup
[AppServerConnection] response_orphaned requestId=config/batchWrite:&lt;uuid&gt;
</code></pre>
<h2>Isolation (A/B/A tested, same session series, restart between each step)</h2>

Configuration | @ result
-- | --
All 10 plugins enabled (stock) | Freeze
All plugins disabled | OK

• documents/pdf/spreadsheets/presentations/template-creator | OK
• chrome | OK
• computer-use | Freeze (first try, ~30s after launch)

computer-use disabled again, everything else re-enabled (incl. full curated catalog, remote_plugin=true, MCP servers) | OK, repeatedly

<p><code>computer-use@openai-bundled</code> is the deterministic trigger. With it disabled the picker opens in under 3 seconds every time, including immediately after launch with the full 12-bundle curated catalog loaded.</p>
<h2>Why the 86-107s duration</h2>
<p>The Computer Use Windows helper (<code>codex-computer-use.exe</code> / <code>node_repl</code> native pipe, <code>SKY_CUA_NATIVE_PIPE</code>) fails to start on this machine. The generated <code>mcp_servers.node_repl</code> config has <code>startup_timeout_sec = 120</code>. The freeze durations match waiting on that backend. When the <code>@</code> picker triggers plugin/tool listing on the shared app-server stdio connection, everything behind it (including <code>app/list</code> and <code>config/batchWrite</code>) stalls until timeout, and request promises are dropped so late responses arrive orphaned. This looks related to the "computer-use native pipe startup failed" reports already in this issue.</p>
<h2>Ruled out during isolation</h2>
<p>Restart/update, renderer profile reset (full <code>web/Codex</code> rename), <code>mentions_v2</code> off, <code>apps</code> feature off, <code>remote_plugin</code> off <strong>with the curated cache physically moved away</strong>, MCP servers (<code>node_repl</code>, third-party) fully removed from config, workspace size, WMI perf counter corruption (see below), Defender, memory pressure. The freeze survived every one of these except disabling the computer-use plugin.</p>
<h2>Secondary bug worth a look: foreign error surfaces in marketplace folder write</h2>
<p>This machine initially had corrupt Windows performance counters (<code>Get-CimInstance Win32_PerfFormattedData_PerfProc_Process</code> returned <code>Invalid class</code>, HRESULT 0x80041010). While that was broken, one session logged:</p>
<pre><code>[BundledPluginsMarketplace] plugin_marketplace_folder_write_failed
errorMessage="Command failed: powershell.exe ... Get-CimInstance Win32_PerfFormattedData_PerfProc_Process ..."
folderWritePhase=stop_chrome_native_host
pluginCountBeforeWrite=6 pluginCountAfterWrite=4
</code></pre>
<p>The error text belongs to the <strong>electron-sampler's</strong> process-snapshot command, yet it aborted the <strong>marketplace folder write</strong>, leaving a partial marketplace (6 -&gt; 4 plugins). That suggests a shared child-process error path where an unrelated failure can abort marketplace writes mid-flight (matching the partial-marketplace race described in #33714). Rebuilding perf counters (<code>lodctr /R</code>, <code>winmgmt /resyncperf</code>) removed the <code>Invalid class</code> errors but did not fix the <code>@</code> freeze; only disabling computer-use did. The same phase also emits dozens of <code>taskkill.exe</code> exit-128 spawns per minute.</p>
<h2>Workaround</h2>
<pre><code class="language-toml">[plugins."computer-use@openai-bundled"]
enabled = false
</code></pre>
<p>Restores full <code>@</code> picker function immediately. Happy to provide redacted breadcrumb logs, the full isolation timeline, or run a debug build.</p></body></html><!--EndFragment-->
</body>
</html>