Codex App frequently freezes/stutters on Windows 11 Pro despite sufficient system resources

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

• #18997
• #19923
• #20171
• #18693
• #19936

Powered by Codex Action

I checked Windows Task Manager while the Codex App was freezing/stuttering. CPU usage was not maxed out, RAM was not maxed out, and disk usage was not maxed out either.

My system drive is an NVMe SSD, so this is not a hardware bottleneck. Other applications remain responsive during the issue.

Based on this, I believe the problem is related to Codex App optimization on Windows rather than insufficient system resources.

Similar experience. Codex app is not usable on Windows for me (is anyone actually using the app on Windows successfully and what is their setup?)

YES! I am having this problem too! What is happening..... :( Jus started happening the last two days on this machine. Not sure what to do!

same here as well windows 11 pro as well

Same here. Became noticeably slower this week. Starting freezing yesterday. Freezing every 15 min now. I keep rebooting. Frustrating.

Edit, in case that helps:

What I found: - The app keeps starting browser-use/browser sidebar even when browser-use@openai-bundled is disabled. - The desktop frontend repeatedly asks the backend to enable workspace_dependencies, but the backend rejects it as unsupported. - The primary runtime was stale or missing; I forced a runtime refresh and it installed 26.430.10722. - The app is still package version 26.429.3425.0.

codex suck.... I run in my macos keep crashing

Same

Removed from PC, I only use this from MacOS because its built for Unix systems and it sucks on W11 Pro even though I have high-end system setup.

How have they not fixed this issue at all? The constant freezing is absolutely ridiculous when you pay these people $200>+ a month.

Gets progressively worse as the chats increase in quantity and length. Every new message hangs the app. Went from a few seconds to a little over a minute at this point.

Update: I'm going on 5 min now.

Gets progressively worse as the chats increase in quantity and length. Every new message hangs the app. Went from a few seconds to a little over a minute at this point. Update: I'm going on 5 min now.

You have to start a new chat, the issue appears to be related to cached files or workspace bloat. Something they seriously need to resolve if they want to have large context windows.

> Gets progressively worse as the chats increase in quantity and length. Every new message hangs the app. Went from a few seconds to a little over a minute at this point. > Update: I'm going on 5 min now. You have to start a new chat, the issue appears to be related to cached files or workspace bloat. Something they seriously need to resolve if they want to have large context windows.

Interesting, this does seem to help a bit. Not perfect, but much better. Ty.

Agreed. I'm having massive issues with the Codex Windows App, It is constantly freezing, to the point where if I run a sprint it doesn't even show me updates of what its working on. Will try the chat thing, if that doesn't work its off to a different platform.

payed 200$ and codex sucks on w11 Surface Pro 9
adding 1+2 takes 15 minutes and hangs
https://www.youtube.com/watch?v=lwpNkSYjJl8

<img width="1919" height="1079" alt="Image" src="https://github.com/user-attachments/assets/c3d1f8b3-632f-4ae8-b00c-50eb140e5e18" /> i found codex is pretty bloated and some features are turned off for windows users im fixing that right now and gonna opensource it stay tuned

Maybe they can use fable 5 with claude code to fix the issue?

10 seconds freeze when switching already-loaded chats; 10 seconds unresponsive input on new chat; fast NVMe; Defender/search indexing exclusions already tested.
Unfortunately it is no fun to use it daily.

Suggestion: Make 20% of the Codex team develop on Windows. Problems will be solved in a week.

got the same issue, surprisingly there hasn't been a fix after all this time ...

got the same issue

same issue

i suspect its to with codex now running through windows store, i got the same issue. windows store, windows eperience host, all links windows trying put is maybe on to different GPU, etc. might also be the appx core windows store apps use. I reloaded windows, updates all winget, etc same issue. if i switch the using wsl seems faster but the codex does not have access to my code, and does have acces to old session.

Same issue on modern hardware.

+1

I really would like to hear from a happy Windows codex app user. I have tried the app for a few hours every few weeks and always give up bc too buggy too slow. I report the bugs. Then back to CLI on WSL which works great.

Surely someone is happily using this app on Windows. What is your setup? How do you use the app?

Maybe they can use fable 5 with claude code to fix the issue?

In my opinion, GPT-5.5 (low or medium) might not always take everything into account (needs more guidance), but overall it makes fewer mistakes than 'high' or 'xhigh'. Low or medium reasoning follows instructions more precisely. I get the feeling that two bugs are constantly being fixed while five new ones are introduced.

Also 32 GB RAM here. Same problems for weeks.

Hello everyone, I found that when this issue occurs, the following commands can temporarily fix it. Please close Codex or VS Code before running them.

The commands are:

rmdir /s /q "%APPDATA%\Code\Cache"
rmdir /s /q "%APPDATA%\Code\CachedData"
rmdir /s /q "%APPDATA%\Code\Code Cache"
rmdir /s /q "%APPDATA%\Code\GPUCache"
rmdir /s /q "%APPDATA%\Code\Service Worker"

Same here, the Codex app freezes intermittently on Windows 11 Pro. Moreover, after today's update, the ChatGPT Classic app appears to run on very low FPS, i.e., mouse movement feels like 60 fps on 144Hz monitor.

Same issue

Same issue here as well. More than enough system resources available, but windows as whole stutters wildly when using codex. when using codex through cli, there's no issues at all. I didn't have this until using it through Windows Shop.

Have you tried /goal on Sol Ultra @openai just a thought

Few thinks that helps. check acls windows folder permissions. the codexsandbox user needs access it folders, and stop WSL

I found this symptom asking for many folders to be archived. Click click click rapidly archiving and instead of sensibly stepping through them the whole system freezes up and stutters.

Another trigger is spinning up several forks at once. Click click click on the "Continue in new task" button and the whole system seizes

Another trigger is resizing the window(!)

when to fix it? toooooo slow for windows

I also see intermittent UI hangs/stutters specifically when creating or opening a new chat/task. This has been happening across multiple Codex app versions, not only the latest update.

Environment at the time of this report:

• Codex app: 26.707.9564.0
• Windows 11 Pro, build 26200, x64
• HP Pavilion 17
• Intel Core i5-3230M
• 8 GB RAM (about 3 GB free during inspection)
• Intel HD Graphics 4000

The machine is modest/old, but model inference is cloud-hosted and the delay occurs in the local task-creation/UI path before useful model activity begins. Codex/ChatGPT processes were using roughly 1 GB RAM in total during inspection. A visible loading state and diagnostics for local session initialization would help.

Codex/GPT windows app worked fine, but I updated it and it seemed to work fine, imported a conversaion as task and it is compltely frozen and consumes all PC resources and never updates it UI whenever I click that chat. The only solution is to force kill everything, and then it works until I try to open that chat again. Non task chats work fine, but that chat crashes everything upon opening. The weird thing is it stills runs and mutates files. I had it create markdown files. It created them but the UI was empty and the PC overheating and full throttle. It's a top tier desktop PC and runs other apps fine. Paying per month for gpt pro and this prevents me from getting money's worth.

I've been running into this issue for at least a few weeks now, but it seems like the lag times have gotten worse. I'm on a Windows 11 Home, but I have a decent graphics card and 32GB of RAM. As is the case with others, system resources are fine, but as soon as I try to type in a new chat or when I open up an old chat, there's a lag spike that often lasts 3-5 seconds.

Adding another data point from a ChatGPT Pro subscriber on Windows 11.

I am seeing the same severe desktop-app UI lag: switching chats, typing in the composer, and sending messages all stutter or temporarily freeze. This happens during ordinary use, while the rest of Windows remains responsive. Task Manager shows roughly 5% CPU usage and about 50% system memory usage, so this does not appear to be a hardware-capacity issue.

Details from my machine:

• App package: OpenAI.Codex_26.707.9981.0 (Microsoft Store)
• Changing the app language from zh-CN to en-US made no difference.
• Windows Event Viewer recorded repeated ChatGPT.exe crashes at 2026-07-16 09:51, with exception code 0xc06d007f, for the same OpenAI.Codex package.

This is disruptive enough to prevent normal daily use. As a Pro subscriber, I do not feel the current Windows desktop experience provides value commensurate with the subscription while basic interaction is this unreliable. Please prioritize investigation, provide a reliable workaround, or share the status of a fix.

I can reproduce this consistently on a current Windows build, and I collected a process trace plus controlled A/B results.

Environment

• Codex Microsoft Store package: 26.707.12708.0
• Windows 11 Home 10.0.26200 (build 26200)
• Intel Core Ultra 7 256V, 8 logical processors
• 15.66 GB RAM
• Other applications, including Chrome, remain responsive

Exact symptom

Switching to another task/chat normally stalls the Codex UI for 1–2 seconds and sometimes 5–6 seconds. During the longer stalls, Windows greys the app as Not Responding and shows the busy mouse cursor. This started abruptly after the same workflow had been responsive about a week earlier.

Process trace during repeated task switching

A 45-second trace sampled the Codex processes 40 times:

• Main desktop process reported NotResponding in 34/40 samples
• Main process private memory: max 2.15 GB
• Main process CPU: p95 109%, max 120%
• Main process page faults: p95 153,545/sec, max 188,892/sec
• Renderer CPU: max 138%
• GPU process CPU: max 81%
• Bundled codex app-server: average CPU only 0.68%

This looks like the desktop main/renderer path blocking rather than the backend agent loop or general system resource exhaustion.

Correlated app-server evidence

Each affected task switch produces a thread/resume request. The local diagnostic database then records a large rmcp::service TRACE entry:

• Estimated row size: approximately 1,249,644 bytes
• input_schema occurrences: 277
• Reproduced on multiple task resumes
• Reproduced again after starting with a completely fresh diagnostic database

This may indicate that a roughly 1.25 MB tool/schema catalog is being serialized, logged, transferred, or parsed on each resume. I cannot prove that it is the cause, but the timing and repetition are notable.

Controlled tests that did not help

• Full app removal and reinstall
• Clearing/replacing Codex application caches
• Restarting Windows and Codex
• Clean/empty local task-history test
• Opening empty/new tasks
• Resizing the app window
• Closing Explorer search activity
• Moving the existing ~50 MB logs_2.sqlite database aside and letting Codex create a fresh one

The fresh-log test was valid and did not change the lag, so accumulated log size is not the main cause.

I also attempted app/connector-disable configuration tests, but the current desktop build continued loading the identical 277-schema payload, so those tests were ineffective and should not be interpreted as ruling connectors in or out.

I have not attached raw logs because they can include private task/tool data. I can provide a specifically requested redacted excerpt or additional counters if a maintainer says what would be useful.

Still reproducible on the current Microsoft Store build 26.715.2305.0 (2026-07-17). I also reproduced the same severe Windows UI lag on 26.707.9981.0 and 26.707.12708.0, so it has persisted across two updates.

Environment

• Windows 11 Pro for Workstations x64, 10.0.26200
• Intel i5-12500 (6C/12T), 24 GB RAM
• Local projectless/non-Git task with a long diagnostic thread
• Session metadata only: 136 JSONL files under ~/.codex/sessions, 453.5 MB total, largest 43.2 MB

Measurement while the UI was laggy

10-sample PowerShell/WMI trace:

• Main ChatGPT.exe CPU: 49.1% average, 104% max
• C: physical disk active time: 6% max
• C: average disk queue length: 0 throughout

This points more toward the Electron main/UI/session-history path than physical disk saturation.

I also ruled out SQLite feedback-log churn (#28224) as the immediate cause here:

• RUST_LOG=error
• ~/.codex/logs_2.sqlite: 0 rows, MAX(id)=NULL, 40 KiB
• a local BEFORE INSERT ... RAISE(IGNORE) workaround is installed
• the lag remains with persistent log inserts eliminated

The 453.5 MB session directory may amplify the problem, but I cannot prove causality. This looks consistent with #20867 and #28109.

Expected: the Windows UI remains responsive during active tasks and long conversations; session-history parsing/rendering should not monopolize the main process.

No session contents or private paths are attached. I can collect a redacted ETW/WPR trace if maintainers specify the preferred profile/capture window.

Codex is unusable for me right now.

Today, it started hanging for minutes on every minor action.

Repaired, resetted, reinstalled.

All to no avail.

I cannot use Codex. My productivity is at a standstill.

Update (2026-07-20): This early 42-second observation has been superseded by a controlled five-minute same-build A/B and an existing blocking stack documented in #33884.

Because #20214 covers broader Windows UI-performance symptoms, please use #33884 for this specific periodic voice-input/AppHang investigation. This comment is retained only as a pointer and should not be read as current root-cause evidence.

With these settings, it lags less. It still lags when launching the app, but once it’s running, opening new chats no longer causes lag with these settings:

[features]
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
computer_use = false

[plugins."chrome@openai-bundled"]
enabled = false

[analytics]
enabled = false

Adding a new data point from Microsoft Store build 26.715.4045.0 after updating from 26.715.2305.0. The UI freeze is still reproducible on the newer build.

Environment

• Windows 11 Home x64, build 10.0.26200
• Codex Microsoft Store package: OpenAI.Codex_26.715.4045.0_x64
• Updated package status: Ok

Symptom on a normal Store launch

The desktop UI still freezes during ordinary use after the update. During one captured affected launch, the oldest ChatGPT.exe process reported Responding=False in 6/6 samples over approximately 12 seconds, while the other Codex processes remained responsive.

There were no new Application Error/Hang events (1000/1001/1002) and no new crash dump for this build, so I am not claiming that this is the same 0xC06D007F native-addon crash fixed in #33375/#33518.

Package inspection

The updated package no longer contains serialport.node, consistent with the earlier packaged fix. However, app.asar still contains a startup-time CodexMicroService load of:

createRequire(__filename)("@worklouder/device-kit-oai")

The service still destructures the same device-kit exports (ConnectionEventType, DeviceType, OAILightingEffect, RPCApiOAI, WLDeviceCommImpl, and WLDeviceDiscovery).

For reproducibility, the app.asar SHA-256 on this installation is:

4F81FE8CFADD0ECD1D55A46F4B101B1DB70ABBB372B63A0120218B1D868008A3

Controlled A/B observation

I relaunched the exact same signed Store package and user profile with a process-local startup hook that replaces only @worklouder/device-kit-oai with a no-device stub. It does not modify the package, registry, configuration, or app data; the loopback inspector used for startup injection is closed immediately afterward.

Result with the optional module stubbed:

• all 7/7 Codex desktop processes remained responsive in 10/10 samples over 20 seconds
• new Application Error/Hang events (1000/1001/1002): 0
• the user reports that the UI is usable again
• removing the stub and launching normally reproduces the freeze

This is a single-machine A/B correlation, not proof that the WorkLouder path is the sole root cause. It does show that the original serialport.node removal did not eliminate the newer freeze on this installation, while preventing this optional module from initializing changes the result materially.

Could a maintainer confirm whether the Windows feature gate is expected to prevent the module from being loaded at all, rather than only preventing device connection? If a matched ETW/WPR trace would help, please specify the preferred profile and capture duration; no raw dumps or private task data have been posted.

Follow-up from the same machine as my earlier report, now on Microsoft Store build 26.715.4045.0.

More precise trigger

The sidebar can become completely unresponsive, but the latest captured session was initially usable after a fresh renderer/app process. The unresponsiveness returned immediately after starting a task turn.

The local backend was responsive during the affected window:

• thread/list: 1–56 ms
• turn/start: 13 ms and 138 ms
• thread/resume: 817 ms
• No corresponding backend stall or system-wide memory/CPU exhaustion was observed
• Chrome and the rest of Windows remained responsive

Renderer correlation

Immediately after the first turn/start, the desktop log began emitting dense bursts of:

ResizeObserver loop completed with undelivered notifications.

There were 15 such renderer errors over roughly 4.4 seconds after that turn start, with later bursts including about 10 errors within approximately 300 ms. The captured session recorded 33 total ResizeObserver errors. The feature log for the same session showed concurrent_reasoning_summaries enabled and the turn configured with summary=detailed.

A new renderer/app process at 22:31 made the UI responsive again without a package, configuration, or conversation-data change. This points more strongly to a live renderer/layout loop during task updates than to slow thread storage or insufficient memory.

Bundled-plugin observation (probably secondary)

The same startup first logged a bundled-marketplace write failure in stop_chrome_native_host, but a queued retry then succeeded and completed reconciliation. A manual cache comparison/repair did not prevent the task-triggered freeze, so I no longer consider the plugin cache the primary explanation for this symptom.

No private task contents or raw logs are attached. I can provide a redacted timestamped excerpt or capture a matched healthy/failing renderer trace if maintainers specify the preferred format.

I isolated two separate Windows defects and now have a combined workaround that has fully resolved the observed problem on the affected machine for almost 24 hours of heavy Codex use.

1. Periodic HID/Codex Micro stalls

ETW measured 203–219 ms Electron-main-thread stalls approximately every 10.21 seconds, with HID.node in the Windows device-enumeration path. In a backup-protected writable copy of app.asar, replacing:

this.discovery.findWLDevices([a.Project2077])

with [] plus same-length ASCII padding completely removed those pauses. Controlled 26-second A/B probes measured three >=180 ms delays in the original runtime (maximum 499.79 ms) and zero >=50 ms delays in the patched runtime (maximum 4.70 ms). This intentionally disables optional Codex Micro / Work Louder discovery. Details: #33912 and #33780.

2. Fine renderer choppiness and persistent DWM degradation

A distinct symptom consisted of dense ResizeObserver activity and fine sub-second choppiness that spread to desktop animation and video. In the same backup-protected copied runtime, replacing:

n?(0,Oe.flushSync)(I):I()

with n?setTimeout(I):I() plus same-length padding, forcing the bundled reduced-motion resolver to return true, and launching with --force-prefers-reduced-motion prevented recurrence in the final configuration. The AMD integrated display adapter was also disabled, leaving the RTX 4090 as the only active display adapter, followed by a Windows restart. Renderer details: #33996.

Important recovery finding: closing every Codex / ChatGPT.exe process did not clear the already-triggered system-wide choppiness. DWM remained degraded after Codex exited. Win+Ctrl+Shift+B, G-Sync changes, Docker/WSL shutdown, and the translucent-sidebar setting did not recover it.

The immediate recovery was to save work, fully close Codex, open an elevated PowerShell, and run:

taskkill.exe /F /IM dwm.exe

Windows automatically relaunched dwm.exe and smooth desktop/video rendering returned immediately. Sign-out or reboot is the fallback.

The archive edits are unsupported and exact-pattern/version-specific; they are diagnostic workarounds, not acceptable product fixes. But on this machine the controlled HID A/B test and the subsequent almost-24-hour heavy-use run establish that the combined mitigation resolved the entire observed freeze/stutter problem, including the persistent post-Codex DWM state.

I get the same problem in the latest version, i tried unistall, use different system (intel instead of amd), but still you cant navigate. And when it opens it runs the tasks that was frozen on the bg..the ui is frozen but the tasks are running...and the funny of the story is that i used codex cli to continue that tasks i was working and i realised accidentally that both app and cli was working to the same taks(the difference is the app was in a worktree. That been said it burned all the weekly usage in a single day.
Version: 1.2026.190.0
Package: OpenAI.ChatGPT-Desktop (Windows app package)

Logs (collected from Windows Event Viewer via PowerShell)
1) Application Hang (1002)

• 2026-07-18 06:53:06 → ChatGPT.exe version 150.0.7871.124 stopped interacting with Windows and was closed
• 2026-07-18 04:51:31 → same message
• 2026-07-18 04:36:27 → same message

2) Application Error (1000)
Burst of crashes with:

• Faulting application: ChatGPT.exe
• Exception code: 0xc06d007f
• Fault offset: 0x00007ffd20d01ada
• Faulting process id: 0x163F0
• Faulting package full name: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
• Path: C:\Program Files\WindowsApps\OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe
• Faulting module: unknown (0.0.0.0)
• Several report IDs generated (e.g. 193c62a0-77c0-4a0c-99f7-c62b06329c0f, 5b782c7e-3ce3-45f3-b6c7-76c544e243e6,

etc.)

UPDATE:
Version 26.715.52143, released this July 20th, has fixed the problem for me.

Hi all, please quote the exact version number you are on as this problem has been better and worse depending on the version

Hi all, please quote the exact version number you are on as this problem has been better and worse depending on the version

Had to wait for a 2 minute hangup on startup, but was eventually able to retrieve the version: 26.715.31925.

A trigger is picking up and moving the Pet around - big lag big stuttering (on 26.715.31925)

I never use the pet.

26.715.31925 getting worse and worse through the day

Another live capture from the same machine, now on Microsoft Store build 26.715.7063.0.

Visual state

The sidebar became dimmed/disabled with task-row loading spinners and stopped accepting interaction. This was an app-rendered loading/disabled state, not the generic Windows full-window “Not Responding” overlay. It later cleared by itself without restarting Codex.

I am not attaching the screenshot because it contains task names.

Same-process affected vs recovered comparison

I sampled the Codex process tree for approximately 15 seconds while the sidebar was unresponsive, then sampled the same process IDs again after the UI recovered spontaneously.

| Process | During sidebar freeze | After recovery |
|---|---:|---:|
| Primary renderer (same PID) | CPU max ~118.8%; private memory max 409.2 MB | CPU avg/max 0%; private memory max 423.3 MB |
| GPU process (same PID) | CPU max ~37.5% | CPU avg/max 0% |
| Main desktop process (same PID) | CPU max ~34.4% | CPU avg ~1.5%, max ~9.4% |
| App server | CPU max ~18.8% | CPU avg ~7.4%, max ~25% |

All sampled processes still reported Responding=True during the sidebar freeze, despite the sidebar being unusable.

Interpretation

Because the UI recovered with the same renderer PID and renderer memory did not fall, this does not look like immediate RAM pressure, database latency, or a process restart. The strongest correlation is a transient renderer/GPU busy loop that leaves the sidebar in a disabled/loading state.

This is consistent with the earlier ResizeObserver loop completed with undelivered notifications bursts observed immediately after turn/start on build 26.715.4045.0, but the current build's active log file was still buffered/empty during the live capture, so I cannot yet confirm the same error text for this exact incident.

A sanitized CSV of timestamped process counters was retained locally; no conversation contents were collected.

Version 26.715.52143, released this July 20th, has fixed the problem for me.

Version 26.715.52143, released this July 20th, has (tentatively) fixed the problem for me.

OK so freezing and stuttering appears to be fixed on 26.715.52143, but parts of the app are still ghastly slow (like switching between chats).

I withdraw my report that it's fixed. Back to stuttering when navigating chats and opening settings for me on 26.715.52143. Closing the ChatGPT app completely resolved the issue.