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.

I started experiencing what appears to be the same issue yesterday.

Initially, I noticed it while using the Codex extension in Cursor. Codex became extremely slow, frequently stalled while working, and sometimes failed to complete tasks. Today, I downloaded and tested the Codex desktop app and encountered the same behavior there as well.

Environment details:

• Windows 11 Pro, version 25H2
• Windows x64
• 16 GB RAM
• Repository stored on local Windows storage
• Not using WSL or network-mounted storage
• Model: GPT-5.6

I checked Windows Task Manager while the issue was occurring. CPU and memory usage appeared normal, sufficient storage was available, and I did not see any stuck or suspicious processes. Other applications continued to work normally.

Since the slowdown occurs in both the Cursor extension and the Codex desktop app, it may not be limited to one interface. There may be a shared Codex runtime, backend, or communication bottleneck involved. I cannot confirm the exact cause, but the issue does not appear to be caused by WSL, network storage, or obvious local resource exhaustion.

26.715.70719 horrendous.

Worked ok for an hour or so, then I had 8 agents going at once and it started getting choppy. Persisted for a long period and task manager showed abundant resources.

I sent a performance trace - it didn't give me a trace id (which is also a bug?)

#34450 possibly related

26.715.71837 Not fixed yet.

WMI still uses over 80% CPU, making the system unusable, and the only workaround is using the CLI.

For me, it happens whenever I open any long existing chat or conversation. I even left my laptop ON overnight to see if the process would finish, but the CPU stayed at 100% even after 9 hours. Seems like something is going in loop.

_Surprisingly, ChatGPT still hasn’t fixed this issue despite there being over 66 open items related to high CPU. Looks like GPT-5.6 Sol can’t figure it out either :). I saw a demo of automatically picking items from Git, fixing and reviewing. I’ve never tried it, but it seems like it was just marketing since they have 5k open items. :)_

26.715.71837 no improvement

If you land here, please run a performance trace

<img width="213" height="323" alt="Image" src="https://github.com/user-attachments/assets/f8ebc4c6-48a6-4557-9119-e34ea5c97a71" />

stil freezing

Following up on my previous comment, I carried out additional testing and reproduced the latency issue in the same local Windows repository.

The repository and local environment appear healthy:

• Approximately 1,502 repository files
• git status --short: approximately 176 ms
• rg --files: approximately 69 ms
• Repeated targeted Git and rg operations: under two seconds
• CPU usage: approximately 19%
• Physical disk queue: approximately 0.002
• No .git lock files
• Node processes effectively idle

Despite this, Codex tool calls took approximately 55–300 seconds to return. Several Get-Content, Git diff-content, and broader directory reads produced no output and remained blocked until manually terminated.

The most serious behavior involves apply_patch. Files can be modified promptly, as confirmed by filesystem timestamps, while the tool call remains blocked for an additional 3 to 5 minutes. If interrupted, a multi-file patch can be only partially applied, leaving earlier changes present and later changes missing.

This does not appear to corrupt Git repository objects, but it does leave the working tree inconsistent and creates a risk of duplicate, reversed, or conflicting edits if the operation is retried without manually inspecting the diff.

The issue affects both Codex Desktop and the Codex extension. Based on the measurements, Git, repository size, disk activity, CPU load, Node processes, and the local commands themselves do not appear to explain the delays.

Possible areas to investigate include:

• Tool-dispatch or result-delivery queue stalls
• Completion-reporting failures after an operation has already finished
• Stale execution state following interrupted tool or patch operations

At this point, Codex is effectively unusable for normal development work in this repository. Even read-only operations can stall for several minutes, while write operations cannot be trusted to complete fully or report their final state reliably. Manually checking git status and reviewing exact diffs after every stalled operation removes the practical benefit of using Codex.

Please investigate why locally inexpensive operations remain blocked for several minutes and why interrupted multi-file patches can leave partially applied working-tree changes without a definitive result.

Confirmed workaround / regression update for the Windows desktop app:

• After updating to Codex desktop 26.715.10079.0, the sidebar became fully unresponsive again.
• The previously applied config was preserved:

``toml
model_reasoning_summary = "none"
model_supports_reasoning_summaries = false
``

• Despite those settings, the desktop log repeatedly reported:

``
Concurrent reasoning summaries feature override resolved featureOverride=true
`
One session processed **436** Reasoning summary` events. The main/backend processes remained responsive, and CPU/memory were not saturated when the sidebar was locked.

• Restarting only the primary Electron renderer immediately restored the UI while the main Codex process/backend remained alive.
• The persistent workaround was to explicitly add:

``toml
[features]
concurrent_reasoning_summaries = false
``
and then restart Codex.

• The bundled CLI confirmed:

``
concurrent_reasoning_summaries under development false
``

• After restarting and testing task switching, the reporter confirmed that the sidebar issue was solved.

On this machine, the A/B result strongly isolates the desktop's forced concurrent_reasoning_summaries override as the trigger. The remote gate visible in the installed bundle is 2508143457; it appears to bypass the model-level reasoning-summary settings above.

Confirmed root cause: touchscreen scroll leaves the sidebar in a stale drag state

Correction to my earlier updates: disabling concurrent_reasoning_summaries only appeared to solve this temporarily. The freeze is reproducibly triggered by touch-scrolling the task sidebar.

Reproduction

1. On a Windows touchscreen device, open the Codex task sidebar.
2. Drag a finger vertically as if scrolling.
3. The sidebar sometimes becomes greyed out/unresponsive. The rest of the app/Windows remains usable.
4. Restarting may temporarily clear it, but using touch in the sidebar can trigger it again.

Observed on Codex App build OpenAI.Codex_26.715.10079.0_x64 (Windows 11, Chromium 150.0.7871.124, 125% scaling).

Renderer diagnosis

I inspected the live renderer through the local Chromium DevTools Protocol:

• Sortable task/project rows have touch-action: none (Tailwind touch-none), so a vertical finger gesture is handled as drag-and-drop instead of native scrolling.
• After the failure, the DnD context's authoritative active value/reducer state is already null, but a higher Codex drag wrapper still retains stale drag-source/overlay hook state.
• Its render-prop isDragging therefore remains true.
• The sidebar scroll container conditionally receives pointer-events-none from that value, making the entire sidebar appear frozen.
• Calling Codex's existing onDragCancel callback with the original drag data immediately clears the stale state and restores pointer-events: auto, without restarting the renderer.

Working local workaround

I injected a session-local workaround that:

1. Forces touch-action: pan-y !important on the sidebar and its sortable task/project rows, allowing normal vertical touchscreen scrolling.
2. Detects only stale touch-originated drag state and invokes the app's own onDragCancel.
3. Leaves mouse drag-and-drop unchanged and does not cancel a legitimate DnD context with a non-null active drag.

After this change, touchscreen scrolling works and the sidebar remains responsive in repeated testing.

Things that did not fix it

• Reinstalling/clearing cache
• Closing OneDrive or Explorer search
• Resizing the app/window
• Software rendering/GPU experiments
• Chromium gesture/fling flags
• Disabling SendEmptyGestureScrollUpdate
• Disabling concurrent_reasoning_summaries (temporary false positive)

Suggested product fix

• Allow vertical touch panning on sidebar rows (touch-action: pan-y), or use a touch-specific drag activation delay/distance.
• Guarantee drag cleanup on touchcancel, pointercancel, and lost pointer capture.
• Do not apply sidebar-wide pointer-events: none from stale wrapper state; derive it from the authoritative active drag state or add a cleanup path.

This explains why RAM/CPU looked suspicious initially but were not causal: the UI was deliberately non-interactive due to a stuck DnD state.

Has anyone tried the claude code Windows app? Is it more stable?

EDIT: I just tried it. It's actually so smooth and stable and has per chat WSL/Windows switching. I have been thinking about moving my sub over anyway to get more Fable access.

not fixed in 26.715.72359

No improvement in 26.721.30844

I disabled Bitlocker and my codex started working correctly.

If interactions with Bitlocker is the cause hopefully that's something they can address. Most of us who have Bitlocker have no option to disable it.

I can reproduce a severe Windows Codex Desktop regression immediately after updating on July 17, 2026.

App version: 26.715.21425 (also observed on 26.715.2305.0 and 26.715.7063.0).

Symptoms include delayed typing, very low-FPS scrolling, UI interaction delays, and brief freezes. The issue affects both existing and new chats.

I have already reproduced it after reinstalling the app, disabling bundled plugins, clearing CodexHome/session data, and launching with --disable-gpu. None of these mitigations helped. The same machine was responsive before the update.

This appears to be a Windows Desktop performance regression in the 26.715 release line. I can provide process CPU/GPU/memory observations or logs if useful.

No improvement in 26.721.41059

Title

[Desktop App][Windows] Mouse stuttering when opening existing task chats or ChatGPT Help details

Description

In the Codex Desktop app on Windows, mouse movement becomes noticeably laggy or stutters while opening certain existing UI content.

Steps to reproduce

Scenario 1: Existing task chat

1. Open Codex Desktop.
2. Open a project.
3. Click an existing task/chat in the project.
4. Move the mouse cursor while the chat is opening or displayed.

Scenario 2: Help / ChatGPT details

1. Open Codex Desktop.
2. Click Help.
3. Select an option that opens the ChatGPT detail/info pop-up.
4. Move the mouse cursor while the pop-up is visible.

Expected behavior

Mouse movement should remain smooth and responsive while switching between existing task chats or opening Help-related detail pop-ups.

Actual behavior

The mouse cursor becomes noticeably laggy or stutters in both scenarios:

• Clicking and opening an existing task/chat in a project.
• Opening the ChatGPT detail/info pop-up from the Help menu.

Reproducibility

Reproducible consistently.

Environment

• App: Codex Desktop for Windows
• Codex version: 26.721.31836
• OS: Microsoft Windows 11 Home Chinese Edition
• OS version: 10.0.26200
• OS build: 26200
• System architecture: 64-bit, x64-based PC
• Device manufacturer: Lenovo
• Device model: 21HW
• CPU: 13th Gen Intel Core i5-13500H
• Memory: 31.73 GB
• GPU: Intel Iris Xe Graphics
• Intel GPU driver: 32.0.101.6733

Additional notes

The issue appears related to UI rendering or event handling, because it occurs specifically while opening existing task chats and Help/ChatGPT detail pop-ups.

Another current-version confirmation: Windows package OpenAI.Codex_26.721.4979.0_x64 is still affected, and performance became noticeably worse again after the latest updates.

On this machine the current slowdown is not explained by an active idle Git storm: a 60.70-second external sample saw only one short-lived Git PID and two short-lived taskkill PIDs, with no residual processes and 184/184 Responding=True checks.

The stronger signals are in the long-lived Desktop renderer/app-server state:

• aggregate Electron working-set peak around 2.09 GiB
• app-server around 650 MiB working set / 1.15 GiB private memory
• three heavy renderer processes around 683, 480, and 349 MiB working set
• local concurrent_reasoning_summaries = false, but Desktop logs resolved the remote override to featureOverride=true 413 times and never to false
• 15,123 reasoning-related log rows and 512 ResizeObserver-loop errors in one 22.5-hour 4979 log
• 11,253 completion rows for only 3,855 unique reasoning item IDs, consistent with roughly three-way renderer delivery
• 420 thread/list responses, with bursts up to 16 per second

The user-visible symptoms are delayed navigation and obvious stutter when switching sessions, while Windows still reports the window as responsive. This supports the reports above that Responding=True and moderate machine-wide CPU do not rule out a renderer-level stall.

Detailed focused evidence:

• reasoning-summary/ResizeObserver path: https://github.com/openai/codex/issues/33996#issuecomment-5084433882
• session switching, thread-list bursts, and Git control: https://github.com/openai/codex/issues/30428#issuecomment-5084435297

No reinstall, config reset, process termination, or filesystem change was performed during this capture.

Send performance traces!

I’m experiencing the same issue on Codex for Windows, version 26.721.4979.0.

The UI visibly stalls immediately after I send a message. This also occurs in newly created threads, so it is not limited to long conversation history. Fully restarting the Codex app did not resolve it.

Local checks:

• 32 GB physical RAM, with about 21.6 GB free during testing
• Codex remained responsive and used about 246 MB RAM
• System disk had about 35 GB free
• Local SQLite integrity check passed

The rest of the system remains responsive; the lag appears isolated to the Codex Windows UI during message submission.

Still a problem on 26.721.81911

Does anyone in this thread not have Bitlocker on?

Additional Windows diagnostics from another reproducible case on Microsoft Store build 26.721.11231.0:

• Windows Error Reporting recorded 40 AppHangTransient events for ChatGPT.exe in 10 days, including two about five minutes apart in the latest session. The rest of Windows remained responsive.
• The reported bug is specifically a mid-typing UI stall: while text is still being entered into the composer, the app becomes unresponsive and opens the wait/kill dialog. This is separate from message submission or steering.
• The chat was already visibly loaded, but the app server was still congested: 5 in-flight requests plus up to 10 interactive requests queued, with background requests expiring after 30–60 seconds.
• In the five-minute window around a hang, app-log timings included:
• thread/search: 7 calls, 48.8 s average, 86.7 s maximum, up to 17.9 s queued
• skills/list: 8 calls, 14.8 s average, 47.2 s maximum
• thread/turns/list: 8 calls, 9.7 s average, 38.0 s maximum
• app/list: 30.0 s maximum
• An invisible, unfocused avatarOverlay renderer repeatedly issued skills/list requests even though the persisted overlay-open state was false. These scans reported 83 entries missing short_description and commonly took 4–47 seconds.
• Typing @ in the composer started fuzzyFileSearch; its start/stop requests queued for as long as 17.4/62.1 seconds. This may be an additional typing-path trigger, but the user also reports stalls during ordinary typing, so it is not a complete explanation.
• The Electron process sampler also failed 45 times because its PowerShell Get-CimInstance probes were denied. This may add repeated process-spawn overhead but does not appear to be the primary cause.
• Negative checks: no SQLite corruption/lock errors, no direct GPU/renderer crash, no display-driver reset near the hangs, and no third-party hook/overlay DLLs injected into the main process. Disk space and available memory were adequate. The installed Store build had no update available.

Correction: an earlier version of this comment cited a later turn/steer / Composer submit failed: no active turn to steer sequence as explaining the lost text. That sequence happened after submission and is a separate issue; it does not explain the mid-typing stalls described here.

The local session store is large (about 11.7 GB), but large stores should be supported; more importantly, these hangs occurred while an already-rendered chat continued background thread/search, thread/turns/list, and skills/list work. Please decouple those operations from the renderer/composer, coalesce repeated overlay/skills scans, and persist draft text independently. The unresponsive dialog should also avoid allowing ordinary typing/Enter to activate a destructive kill/exit choice.

Still not fixed in 26.727.51351

This problem is shockingly bad today

@tibo-openai please put Astra on this one

我也这么认为，让我使用Codex的频率降低

There 2 solution. One you can set fake link to git and powershell to chatgpt app (i use this when I need the official app) you have simply to say to agent where are them, is 95% lag solution.
The ore solution is to use codex CLI, this a 100% lag solution. I have build an app that tho most of the functions of official app but i light way, with work quick and smooth on any computer with parallel execution. It's only and interface, same prompt same result.
Is there on githup https://github.com/SbiriJJ/prompt-lite-plus

Additional reproducible failure mode on Codex for Windows 26.730.8199.0:

The tool itself completes successfully, but the turn never resumes or finalizes.

I observed this in two separate tasks today:

1. A command execution showed completed, while the thread remained active / inProgress and never continued to inspect or deliver the output.
2. A five-image generation task completed all first-pass images. A single corrective imageGeneration also showed completed, but the turn then remained active / inProgress for about 40 minutes without saving or delivering the results.

In both cases:

• the latest tool marker was completed;
• the thread still reported active, with no active flags;
• no assistant message followed the completed tool call;
• follow-up prompts were accepted but remained blocked behind the stuck turn;
• the generated outputs appeared to remain available, suggesting this is a post-tool turn-resumption/finalization failure rather than slow tool execution.

Expected behavior: after a tool reports completed, the turn should automatically resume, inspect the result, save any artifacts, and produce a final response. If resumption fails, the app should surface an error or recover with a watchdog instead of leaving the task indefinitely in progress.

This may be related to the app-server / renderer congestion already discussed in this issue, but the specific failure here is that a completed tool call does not transition the turn forward.

Title

High CPU usage and mouse freezing when opening chat window on Windows

Description

I noticed that the latest Codex version added a new Task Manager view, which is very helpful for observing resource usage.

While using Codex on Windows, I found that when I open the chat window, the mouse may become temporarily frozen or very laggy. At the same time, the Codex Task Manager shows that CPU usage spikes significantly.

From the Task Manager view, I can see that the Browser process can reach nearly 100% CPU usage, and some renderer processes also consume a high amount of CPU.

Steps to Reproduce

1. Launch Codex on Windows.
2. Open a chat window.
3. Observe system responsiveness and Codex Task Manager.
4. The mouse may freeze or become very laggy, while CPU usage increases sharply.

Actual Behavior

• Mouse becomes temporarily frozen or noticeably laggy.
• CPU usage spikes heavily.
• The Browser process can reach very high CPU usage, close to 100%.
• Renderer processes also show high CPU usage.

Expected Behavior

Opening the chat window should not cause the mouse to freeze or make CPU usage spike dramatically.

Environment

• OS: Windows 11
• Codex version: 26.730.61639
• Screenshot: Attached

Additional Notes

The new Task Manager feature is very useful for diagnosing performance issues.
I hope the Codex team can continue optimizing Codex on Windows and improve its overall performance and stability.

<img width="571" height="326" alt="Image" src="https://github.com/user-attachments/assets/861da944-beeb-4b8d-9c29-846027617026" />

Version 26.803.61601 has not yet been fixed

I don't understand why the program's memory usage suddenly spikes and causes mouse lag even when I just open the Codex interface without launching any task session.

<img width="1298" height="752" alt="Image" src="https://github.com/user-attachments/assets/6e2da826-d0c6-4b06-9197-07ec2fbc85c3" />

Version 26.803.61601 has not yet been fixed I don't understand why the program's memory usage suddenly spikes and causes mouse lag even when I just open the Codex interface without launching any task session. <img alt="Image" width="1298" height="752" src="https://private-user-images.githubusercontent.com/157190784/634008128-6e2da826-d0c6-4b06-9197-07ec2fbc85c3.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODY0NTIwMzQsIm5iZiI6MTc4NjQ1MTczNCwicGF0aCI6Ii8xNTcxOTA3ODQvNjM0MDA4MTI4LTZlMmRhODI2LWQwYzYtNGIwNi05MTk3LTA3ZWMyZmJjODVjMy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwODExJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDgxMVQxMjM1MzRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zZjgzYjcxNjM1NDAxZTc1MDNmZDQ3ODM2NjNhNjYyZTQ5ZTQ1Y2U1ZGYzYzRlNjM5Yzk3Y2M1ODA1MjBiOTE5JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.cq77fKucF9hc3WBlXeT8IDVNpMjHbfx4hoWhrWykvXg">

Use procexp from Sysinternals. You will probably disk search and many git call and powershell call.

> 版本 26.803.61601 尚未修复 > 我不明白为什么即使我只是打开 Codex 界面而没有启动任何任务会话，程序的内存使用量也会突然飙升并导致鼠标延迟。 > <img alt="图像" width="1298" height="752" src="https://private-user-images.githubusercontent.com/157190784/634008128-6e2da826-d0c6-4b06-9197-07ec2fbc85c3.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODY0NTIwMzQsIm5iZiI6MTc4NjQ1MTczNCwicGF0aCI6Ii8xNTcxOTA3ODQvNjM0MDA4MTI4LTZlMmRhODI2LWQwYzYtNGIwNi05MTk3LTA3ZWMyZmJjODVjMy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwODExJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDgxMVQxMjM1MzRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zZjgzYjcxNjM1NDAxZTc1MDNmZDQ3ODM2NjNhNjYyZTQ5ZTQ1Y2U1ZGYzYzRlNjM5Yzk3Y2M1ODA1MjBiOTE5JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.cq77fKucF9hc3WBlXeT8IDVNpMjHbfx4hoWhrWykvXg"> 使用 Sysinternals 的 procexp 工具。你可能会用到磁盘搜索、大量的 git 调用和 PowerShell 调用。

Thank you for providing the solution. We have indeed identified some issues. Below are some summaries of the questions.

Summary

On the Windows Codex desktop app, opening a single session triggers a burst of git.exe processes. During that burst, mouse movement, clicks, and UI interactions inside Codex become noticeably laggy.

The captured evidence shows that Git calls go beyond a simple configuration check: Codex performs repository discovery and working-tree status queries across multiple workspace directories. Some of those directories have never been opened in a Codex session and are not managed by Git by the user.

Environment

| Item | Value |
| --- | --- |
| Operating system | Windows 11 |
| Codex app version | 26.803.81509 |
| Git for Windows | 2.54.0.windows.1 |
| Git executable | D:\LHWStudio\DevTools\Git\mingw64\bin\git.exe |
| Trigger | Start one or more Codex sessions |

User impact

• Opening a session causes obvious mouse and UI lag inside Codex.
• At the time of the Process Explorer screenshot, total CPU usage was approximately 36.89%; the system CPU was not fully saturated.
• A large number of short-lived git.exe, conhost.exe, and related process-creation events appear at the same time.

<img width="1572" height="1184" alt="Image" src="https://github.com/user-attachments/assets/7ad0dd6f-666c-43e9-bea3-73e13cef6244" />

Captured Git commands

The following commands repeatedly appear while a Codex session is opened:

git.exe -c safe.bareRepository=explicit config --null --get core.fsmonitor
git.exe config --null --get core.fsmonitor
git.exe -c safe.bareRepository=explicit -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --path-format=absolute --show-toplevel --git-common-dir
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse HEAD
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -v
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain

Interpretation:

• rev-parse --show-toplevel --git-common-dir: determines whether a directory belongs to a Git repository and obtains repository paths.
• rev-parse HEAD: obtains the current commit.
• remote -v: reads remote configuration.
• status --porcelain: obtains working-tree status in a machine-readable format.
• Multiple status calls explicitly pass -c core.fsmonitor=false, disabling Git file-system-monitor acceleration for those calls.
• core.hooksPath=NUL appears to prevent execution of user-defined Git hooks.

The following capture confirms that ChatGPT.exe directly creates a Git process and invokes config --null --get core.fsmonitor:

<img width="2474" height="1003" alt="Image" src="https://github.com/user-attachments/assets/8ef0be17-ec98-4e10-a9d1-6e0f639751bb" />

The following process-properties view shows one of the Git calls. It starts and ends within the same second, but is repeatedly invoked in bulk:

<img width="1313" height="1082" alt="Image" src="https://github.com/user-attachments/assets/95b07d77-0bd1-4d59-bff3-ebc45f514a78" />

Probing of non-current workspace directories

Process Monitor recorded git.exe probing .git\HEAD under several directories that were not opened in the current Codex session, for example:

D:\LHWStudio\Workspace\Personal\MultiAgentNexus\.git\HEAD
D:\LHWStudio\Knowledge\ObsidianNotes\.git\HEAD
D:\LHWStudio\Workspace\Company\code\.git\HEAD
D:\LHWStudio\Workspace\Company\leadingend\.git\HEAD
D:\LHWStudio\Workspace\Personal\DailyWork\.git\HEAD
D:\LHWStudio\Workspace\Personal\SkillPackage\.git\HEAD

Most events return NAME NOT FOUND. This indicates that Git only attempts to open/probe .git\HEAD; it does not successfully read that file and does not modify the directories. However, the probing scope includes multiple directories outside the current session.

<img width="2088" height="174" alt="Image" src="https://github.com/user-attachments/assets/142b7cdb-7b54-4392-8418-653922032c0d" />

Reproduction steps

1. Launch Process Monitor (Procmon).
2. Capture all events, or filter for Git process-creation events and .git file accesses.
3. Open one Codex session without running a code task.
4. Observe mouse/UI lag in Codex.
5. Stop Procmon and inspect the Command Line, process-creation count, and .git access paths for git.exe.

Expected behavior

• Perform Git detection only for the directory actually associated with the current session.
• Do not probe multiple unopened or non-Git workspace directories when opening one session.
• Cache repository discovery and Git configuration checks to avoid repeatedly spawning many git.exe processes in a short period.
• Throttle and deduplicate git status calls so they do not block or affect UI-thread responsiveness.

Conclusion and request

The available evidence indicates that Codex performs frequent Git probing and status queries when opening a session, potentially across multiple non-current directories. This behavior is strongly correlated with the observed UI and mouse lag, although the current sampling does not prove it is the sole root cause.

Please help confirm:

1. Does Codex keep and poll Git status for historical or otherwise known workspace directories in the background?
2. Is there a setting to disable or limit background Git probing?
3. Can Codex avoid repeatedly running git status --porcelain, rev-parse, and remote -v across non-current directories while opening a session?

Current Windows reproduction on 26.803.10989.0: new/cold tasks still stall after session cleanup and disabling the in-app browser

I can reproduce the same system-wide mouse/UI stutter on the currently installed Microsoft Store package OpenAI.Codex_26.803.10989.0_x64.

Environment

• Windows 11 x64, build 26200
• Intel Core Ultra X7 358H
• 31.5 GB RAM
• Intel Arc B390, driver 32.0.101.8356

The most noticeable triggers are:

1. launching Codex;
2. creating a new task;
3. cold-opening or switching to a task that has not yet been opened in the current app session.

The pointer becomes choppy outside the Codex window as well, so this is not only slow model/network response.

Controlled mitigations that did not resolve it

• I archived 12 large completed tasks. The active session store dropped from about 9.3 GB (including one approximately 1.78 GB rollout) to 502 MB, with the largest active file now approximately 61 MB.
• I disabled only the built-in browser and fully restarted Codex. codex features list confirms:
• in_app_browser = false
• browser_use = true
• browser_use_external = true
• computer_use = true
• The virtual pet is tucked away/not awake.

These changes did not eliminate the new-task/cold-switch stutter.

Post-restart desktop-log timings

From one affected post-restart log session:

| Method | Calls | Average | Maximum | Calls >1 s |
| --- | ---: | ---: | ---: | ---: |
| thread/start | 6 | 2,859.8 ms | 4,388 ms | 6 |
| skills/list | 26 | 2,754.4 ms | 5,636 ms | 24 |
| plugin/list | 15 | 1,355.8 ms | 3,472 ms | 6 |
| config/read | 83 | 297.6 ms | 3,145 ms | 9 |
| thread/turns/list | 6 | 61.7 ms | 184 ms | 0 |

The same log contains 14 main_thread_jank_snapshot events.

This is the important separation in this capture: after reducing the active session store, actual turn-history listing is fast (thread/turns/list averaged about 62 ms), while task startup plus skill/plugin initialization remains multi-second.

There are currently about 168 SKILL.md files across the user, agent, and plugin-cache roots. The log repeatedly reports roughly 151-154 skills missing short_description.

Hidden auxiliary renderer activity

Although the pet is not awake, the desktop log shows an invisible auxiliary renderer:

rendererWindowAppearance=avatarOverlay
rendererWindowFocused=false
rendererWindowVisible=false

That hidden renderer issued at least 15 Skills/list request calls in the same log. Individual calls from it took up to several seconds, for example:

method=skills/list durationMs=3640
method=skills/list durationMs=3835

I am not claiming the hidden avatar renderer is the sole root cause. However, it appears to duplicate expensive initialization even while invisible, and its requests correlate with the same period as the main-thread jank and visible input stutter.

Suggested investigation

Could the desktop client please:

1. avoid bootstrapping task/skill state from avatarOverlay while it is hidden/tucked away;
2. coalesce and cache concurrent skills/list, plugin/list, and config/read requests across renderers/CWDs;
3. keep this work off the latency-critical UI/thread/start path;
4. provide a supported diagnostic switch for disabling auxiliary renderers independently of browser/computer-use features?

This reproduction appears closely related to #33074, #30428, and #29187. I can provide sanitized desktop-log excerpts or submit a feedback ID if a maintainer identifies the preferred private channel.

Additional sanitized reproduction on a newer Microsoft Store build: OpenAI.Codex 26.803.10989.0.

This occurred immediately after relaunch. Windows recorded another AppHangTransient for ChatGPT.exe; Codex recovered without an application-crash event or dump.

Rounded, identifier-free timing evidence from the same startup window:

thread/read                         ~0.3 s
main-thread jank events             4
plugin/installed request A          ~24.1 s
plugin/installed request B          ~24.6 s
plugin reconciliation after hang    ~15 s later
thread/resume request               ~5.3 s

The AppHangTransient event and Codex's main_thread_jank_snapshot occurred in the same one-second window, while the two plugin initialization requests had each been outstanding for about 24 seconds. The initial thread/read completed quickly, while bundled plugin reconciliation finished later. In this occurrence, plugin/skills startup or reconciliation is therefore a stronger immediate correlate than raw thread-read latency, although the selected task was long-running.

The preceding full-machine restart was separately confirmed as planned Windows servicing; there were no unexpected-shutdown, power-loss, or bugcheck events, and no Codex task was active close to that restart. Raw logs are retained locally but are not attached publicly because they contain local paths and task metadata.

Related: #21134, especially the prior startup-restoration/hydration evidence and request to keep the composer independently responsive. This trace suggests plugin initialization should likewise be isolated from the renderer/composer and deduplicated or deferred during resume.

Still an issue on 26.803.81509 (triggered by opening an existing codex task)

Same here! This is so frustrating. v26.810.41047.

It actually gotten worse in the last few days and last update, my PC is not usable when the ChatGPT app is launched, even if I don't use it. I have an i7-11800h with 64GB of RAM and a nvidia 3080 mobile, I don't expect this behavior.

It actually gotten worse in the last few days and last update, my PC is not usable when the ChatGPT app is launched, even if I don't use it. I have an i7-11800h with 64GB of RAM and a nvidia 3080 mobile, I don't expect this behavior.

Remove git, fake git directory (agent can you it anyway) or use my client (the result is identical).

> It actually gotten worse in the last few days and last update, my PC is not usable when the ChatGPT app is launched, even if I don't use it. I have an i7-11800h with 64GB of RAM and a nvidia 3080 mobile, I don't expect this behavior. Remove git, fake git directory (agent can you it anyway) or use my client (the result is identical).

How can I do that?

Same experience here

Possible stdio MCP process accumulation on every chat switch

I can reproduce a deterministic accumulation of node.exe processes while switching between chats in the Codex Windows app. This may contribute to the system-wide UI stutter described in this issue.

Environment

• Codex app: 26.810.6296.0
• Windows 11 Pro x64, build 26200
• NVIDIA GeForce RTX 5080
• Configured stdio MCP servers include Filesystem, MariaDB, and Playwright

Reproduction

1. Fully close Codex.
2. Confirm that no related node.exe processes remain.
3. Start Codex: 7 Node processes appear.
4. Switch to another existing chat: the count increases to 14.
5. Continue switching between chats: each switch appears to add another set of 7 Node processes.
6. Fully close Codex: all accumulated Node processes disappear.

The additional processes include npm/npx wrapper and child processes belonging to the configured stdio MCP servers, including:

• Filesystem MCP
• MariaDB MCP
• Playwright MCP

In one affected session, the accumulation reached:

• 140 node.exe processes
• 20 copies of each of the seven involved Node command lines
• approximately 8.38 GB combined working set
• roughly 430 MB additional working set per accumulated set

The main Codex process itself showed only approximately 324 MB working set. This makes the total memory impact easy to miss when looking only at the Codex process in Task Manager. CPU usage was generally low while idle, but launching or switching chats caused noticeable Windows UI and pointer stutter.

The desktop logs from the same day also contain:

• 4 main_thread_jank_snapshot events
• 1,795 ResizeObserver loop completed with undelivered notifications errors
• 711 Received turn/started for unknown conversation errors
• extensive activity from an invisible avatarOverlay renderer

Hypothesis

This does not prove that MCP process accumulation is the sole cause of the freezes reported here. However, the deterministic increase after every chat switch suggests that the Windows desktop app may initialize a new set of stdio MCP processes without terminating or reusing the previous set.

Expected behavior would be for obsolete MCP child processes to be terminated, or for a bounded/shared server set to be reused across chat switches.

I can provide sanitized process-command details or perform a more controlled A/B capture if maintainers specify what would be useful.

The coming week could be exciting - 94% faster: https://x.com/dboedger/status/2088758720226365930

The coming week could be exciting - 94% faster: https://x.com/dboedger/status/2088758720226365930

Almost certainly these optimisations only apply to mac

Currently seeing 20-30 second freezes when opening a new chat (new regression)

The Codex version 26.818.21641 is suspected to have fixed this mouse lag issue. After the update, I haven't encountered the lag problem for the time being.

I am experiencing this - it's so laggy. My task manager says nothing is in high resources but it's definitely related to chatgpt/codex. IT seems to be from long running sessions (and heavy use of Ultra).