Codex Desktop frequently becomes unresponsive after updating to latest version on Windows

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

• #33839
• #33822

Powered by Codex Action

Mine is freezing non stop on every minor action.

Want to resize the window?

Tough nuts. We're gonna hang. Gotta wait for 2 minutes.

Click the input for focus?

Nope. Hanging for another 2 minutes.

Repairing, resetting, reinstalling didn't work.

I'm currently using Codex from VSCode, because the app has me completely locked out.

I too am experiencing this immediately after updating yesterday evening. It hangs for roughly ~1 minute every ~10 seconds. I turned off all SSH / remote connections, and all settings about "recommended work" - but no go, still problematic.

Same, it's almost unusable. It freezes exactly every 60 seconds, for about 10 seconds.

Experiencing the same as everyone else here with ChatGPT for Windows Version 26.715.21425, Released Jul 16, 2026.

Windows 11 Pro, version 25H2, build 26200.8875

ChatGPT Codex causes Windows to stutter and lag for around 5-10s at a time, like every 30-60s or so. I ran a Performance Trace in Codex during one of the stutters and submitted a bug report in the app with Feedback ID: 019f707a-1e81-7053-89ab-d068d53773da.

_Update 7/18:_ I updated to "Version 26.715.31925, Released Jul 17, 2026", and it's still stuttering badly.

I am experiencing the same issue on Windows.

Reported by: Iván Óscar Sosa Marinangeli
Subscription: ChatGPT Plus
Codex package: OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0
Executable version: ChatGPT.exe 150.0.7871.124

The application freezes and stops responding even after:

• completely uninstalling and reinstalling the Microsoft Store app;
• signing in again;
• testing with a clean/empty .codex directory;
• launching the app before restoring any previous sessions or data.

Windows Error Reporting repeatedly records both AppHangTransient and MoAppHang for ChatGPT.exe / OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0.

The freeze occurs even when the application is effectively empty, so previous Codex conversations and local data do not appear to be the cause. Another desktop AI application works normally on the same computer, which further suggests that the problem is specific to the current Codex/ChatGPT Windows application build.

According to GPT5.6 sol high, this appears to be related to Codex Micro, a gadget introduced by OpenAI
When the ChatGPT App is running or when switching tabs, it indiscriminately loads incompatible drivers and DLLs, severely slowing down the system's mouse
A workaround is to use jetbrains-cc-gui in CLion, or to use the CLI directly in the command prompt or JetBrains Terminal
My computer didn't have any anti-cheat drivers installed at all, and everything was working fine, but while Codex was running as a Windows app, everything including the mouse and window manager was lagging, which was incredibly frustrating. I won't be using the Windows app for a while

https://www.reddit.com/r/codex/comments/1uxtk61/fix_for_windows_severe_app_lag_mouse_freezing/
https://www.reddit.com/r/codex/comments/1uxpr1x/comment/oxtwwhi/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1

Same issue. Codex on windows 11 is completely unusable. I'm on version 26.715.31925. It constantly hangs and becomes unresponsive. I have uninstalled, reinstalled, rebooted and nothing helps. I don't even have to do anything in the app for it to constantly hang.

Same problem here with version 26.715.4045.0

Same issue on a different hardware config — and notably, it is _not_ GPU-vendor-specific and _not_ fixed by disabling GPU acceleration. Adding my data in case it helps narrow the cause.

Environment

• Package: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0
• ChatGPT.exe (Electron/Chromium): 150.0.7871.124
• Windows 11 Pro 25H2, build 26200.8875
• CPU: Intel Core i5-12450H (12th gen)
• GPU: dual — Intel UHD Graphics (32.0.101.7088) + NVIDIA RTX 3050 Laptop (31.0.15.5227)
• RAM: 16 GB

Symptom (matches this thread): the whole window periodically goes unresponsive in a cycle, and while it's hung the entire desktop stutters — the compositor stalls, not just the app. It has gotten bad enough that almost any interaction with the UI triggers a hang — clicking anywhere, focusing the composer, switching views — after which the screen takes on a blue tint, I get the "ChatGPT is not responding" dialog, and it recovers only to hang again on the next interaction. It's usable in brief intermittent windows but otherwise effectively unusable. During the hang the process sits at low CPU with ~7–8 GB RAM free, so it isn't resource exhaustion. Verified first-hand by sampling Process.Responding = False while CPU was low. WER logs repeated AppHang / MoAppHang reports for ChatGPT.exe (Application Error 1000 + 1001 fault buckets), e.g. tonight at 21:25, 21:37, 21:41, 22:08 local.

Things that did _not_ fix it (to save others time):

• Clean uninstall + reinstall from the Store, fresh sign-in, empty profile — still hangs (corroborates @softnerdrd).
• Clearing the app's GPU/shader caches (GPUCache / ShaderCache / GrShaderCache / DawnWebGPUCache).
• Launching with --disable-gpu (renderers confirmed on --disable-gpu-compositing) — still hangs and still stalls the whole system. So this does not look like a purely GPU-compositing regression.

Notable contrast: other Chromium/Electron apps on the same machine (Edge, Chrome) stay perfectly smooth at the same time — so it's specific to this app build, not the OS, drivers, or Chromium in general.

Installed todays update and still not fixed. For what it's worth, I am on a laptop, Framework 13, AMD Ryzen AI9 HX370, with Razor CoreX eGPU (Nvidia 3070). The issue goes away when I disconnect the eGPU.

Codex in VSC found that: "The likely fault is now the desktop update’s SSH integration: desktop app-server 0.145.0-alpha.18 repeatedly terminates the supported remote 0.144.6 proxy every ~70 seconds."

From Codex:
Windows currently marks the ChatGPT browser-main/UI process as non-responsive. Its renderers, Codex backend, GPU process, and network service remain alive.
All recorded OpenAI requests returned 200/202; the backend continues polling normally. Today’s resolved access-denied incident does not match this failure. OpenAI status
Both the package profile and global Codex state were freshly recreated, and the app hung within minutes. The surviving runtime binary exactly matches the newly packaged binary by SHA-256.
Windows recorded the identical hang signature across builds 26.715.2305, .3651, Beta .3651, and the current .4045, all using Electron 150.0.7871.124. No newer Store build is available.
There are no GPU-reset events, overlay DLLs, database corruption indicators, oversized session state, or active disk bottlenecks.
Immediately before hanging, the app logged turn/started and turn/completed for unknown conversation, indicating a conversation/IPC state desynchronization.

My conclusion: the updated Electron main process is losing synchronization with conversation state and stops servicing the Windows UI while its background services continue. Reinstalling cannot fix it because the fault is present in the current shipped build.

I can reproduce this on Windows 11 x64 (build 26200) with the current stable and beta desktop builds, on a ChatGPT Plus account. The behavior is very similar: the app eventually loads, I can perform one or two actions (for example scroll), then clicking a thread/project/UI element makes the whole ChatGPT.exe window become unresponsive.

Troubleshooting already performed

• Completely uninstalled the new ChatGPT/Codex app.
• Removed all local Codex state and reinstalled from scratch.
• Re-added projects one at a time.
• Reproduced on both stable and beta builds.
• Audited the repository for pathologies.
• Git is healthy and fast: no corruption, symlink/junction loop, nested recursion issue, or extreme file count.

Repository diagnostic findings

A repository-local .codex directory had grown to approximately 781 MiB, including about 333 MiB of non-ignored content. During diagnosis, Codex was observed attempting to hash generated binaries and issuing 520 Git commands, 516 of which were cancelled. A burst of activity under .codex/verify correlated within roughly one second with a Windows UI hang.

The repository was then cleaned and hardened:

• .codex/verify and generated/binary/cache content were moved out of the repository.
• Git/Codex ignore rules were added.
• The repository was verified again as healthy and responsive.
• No functional project files were changed.

Despite that complete cleanup, the desktop app still freezes in the same way. This suggests the repository content may be a trigger or amplifier, but it is not the root cause. The underlying desktop app defect remains reproducible after a clean install and with a cleaned repository.

Reproduction

1. Start the current Windows desktop app.
2. Open a local repository.
3. Ask Codex to analyze the project.
4. Wait for the task to complete or for the UI to become interactive.
5. Scroll once or twice, then click another task/thread/project/UI element.
6. The whole window becomes unresponsive and Windows reports that ChatGPT is not responding.

Windows recorded application hangs for both the stable and beta installations, plus a memory pre-leak warning during one diagnostic run.

Hardware note: NVIDIA GeForce RTX 2080 Super. I can provide the sanitized CODEX_DIAGNOSTIC_REPORT.md, screenshots, and exact Windows event details if maintainers need them.

Adding a current 26.715.4045.0 reproduction with an in-app feedback upload.

Feedback ID: no-active-thread-019f7946-5201-7cd1-a08b-58e3ffbba3e7

Build/runtime

• Store package: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0
• Internal build: 26.715.31925
• ChatGPT.exe: 150.0.7871.124

Observed behavior

• A clean app-only relaunch becomes unresponsive before any interaction.
• Opening any existing Codex thread produces “Codex is not responding.”
• Even the in-app feedback form lagged every few seconds while submitting this report.
• Repair, reset, reinstall, profile reset, and repeated clean launches did not resolve it.

Local process/runtime separation

• During the hang, the Electron main ChatGPT.exe process reports Responding=False at low CPU.
• The bundled codex.exe app-server, network service, GPU process, and both renderer processes remain alive and responsive.
• Recorded OpenAI requests returned 200/202; no backend timeout or app-server connection failure was logged.
• A fresh launch creates two renderer processes. App-state telemetry loaded 40 recent threads and read roughly 44–48 MB from app-server stdio during the first 90 seconds. Memory later stabilized, but the UI freezes continued.
• Windows Wait Chain Traversal found no kernel wait cycle; the Electron UI thread appeared running while the top-level window stopped servicing messages.

A prior trace on the immediately preceding build also captured a hidden Quick Chat renderer lifecycle together with MaxListenersExceededWarning and delayed IPC reset/no-handler events. Build 4045 no longer showed the same memory growth, but it retained the second renderer and remained unusable. There is no supported production setting to disable Quick Chat/preloading for isolation.

This evidence points to the unified Windows desktop Electron main/UI path rather than WSL, the local Codex backend, authentication, GPU exhaustion, or system-wide memory pressure. Please correlate the uploaded session logs using the feedback ID above.

Found a working local workaround on my machine (Windows 11 x64, Store package 26.715.4045.0, which embeds internal desktop version 26.715.31925 — so that build still has the bug).

Root cause (matches #33780 / #33912): the desktop host constructs the Codex Micro / Work Louder service on startup, which calls the synchronous, unfiltered node-hid devices() on Electron's main thread, and retries every ~10s when no Codex Micro is found. That main-thread HID enumeration is what stalls the message pump — hence the ~10s "Not Responding" cadence. Confirmed with an A/B test using SendMessageTimeout(WM_NULL) against the Codex window: unmodified = 31 timeouts / 10 hang episodes in 45s; with the workaround = 0 timeouts over 65s, and HID.node no longer loads in the main process.

Workaround — a process-local shim that makes only Work Louder's node-hid import report no devices. It does not patch the signed MSIX, doesn't touch drivers/registry, and doesn't disable any Windows HID device. Other apps are unaffected.

1. Create no-codex-micro.cjs:

'use strict';
const Module = require('node:module');
const originalLoad = Module._load;
const disabledHid = Object.freeze({
  devices: () => [],
  devicesAsync: async () => [],
  setDriverType: () => {},
  getDriverType: () => 'hidraw',
});
Module._load = function (request, parent, isMain) {
  const parentFile = parent?.filename ?? '';
  if (request === 'node-hid' && /[\\/]@worklouder[\\/]wl-device-kit[\\/]/i.test(parentFile)) {
    return disabledHid;
  }
  return originalLoad.apply(this, arguments);
};

1. Fully quit Codex, then launch it with the shim required only for that process (PowerShell):

$exe = Join-Path (Get-AppxPackage OpenAI.Codex).InstallLocation 'app\ChatGPT.exe'
$env:NODE_OPTIONS = "--require=$HOME\path\to\no-codex-micro.cjs"
Start-Process $exe
$env:NODE_OPTIONS = $null

The shim must be present in the first Electron process, so make sure no Codex instance is already running when you launch. To confirm it took effect, check that HID.node is not loaded in the ChatGPT.exe main process. To revert, just launch Codex normally.

Caveat: this disables Codex Micro hardware discovery for those launches (fine if you don't own one), and it's an unsupported shim — the real fix is to move the HID scan off the main thread or add a supported switch to disable Codex Micro discovery.

---

_Disclosure: this investigation and workaround were produced by OpenAI's Codex agent (GPT-5.6, "Sol"); I verified it works on my own machine before posting._

I downloaded Version 26.715.52143, Released Jul 20, 2026, this morning, and the issue of ongoing stuttering on Windows 11 is gone. It still stutters like this for me on startup of Codex for the first 1-2 minutes as the program is loading, along with threads, but it does not continue to stutter beyond that, which is what I experienced before, so this specific problem is resolved for me.

Acabo de probate y eats resuelto! Gracias!
On Mon, 20 Jul 2026 at 11:37 AM silverleafsolutions <
@.***> wrote:

silverleafsolutions left a comment (openai/codex#33873) <https://github.com/openai/codex/issues/33873#issuecomment-5024095973> I downloaded Version 26.715.52143, Released Jul 20, 2026, this morning, and the issue of ongoing stuttering on Windows 11 is gone. It still stutters like this for me on startup of Codex for the first 1-2 minutes as the program is loading, along with threads, but it does not continue to stutter beyond that, which is what I experienced before, so this specific problem is resolved for me. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/33873?email_source=notifications&email_token=B7GE4XEWCHXTCT5EMOJL7W35FY4E5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGQYDSNJZG4Z2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5024095973>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7GE4XFM73GQRVY465DNBUL5FY4E5AVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TIOJRGMZTIMJUHA22C5QC> . 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/B7GE4XDRDNWK6IUNZZVRHP35FY4E5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGQYDSNJZG4Z2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/B7GE4XBSOYH5L3KFUD5JIQ35FY4E5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGQYDSNJZG4Z2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: @.***>

Version 26.715.52143 from July 20th fixes the problem for me.

Sure, it chops a bit on the first minute or two after starting up.

But after that, it's smooth sailing.