Windows Codex Desktop performance has made the app unusable for me since June 12 #29949
Replies: 10 comments 11 replies
|
Adding another current Windows report that appears closely related: This one was opened June 24, 2026 and reports Windows Desktop UI/cursor/input stutters on launch, new chat, first typing, and Settings. It also lists the installed package as The useful part is that this report says the issue reproduced after a fresh reinstall and after deleting Codex data, and their diagnostics also point toward Codex Desktop process CPU/memory spikes rather than disk, GPU, Defender, WSL, or local config. That makes this look less like an isolated machine-specific setup issue and more like a current Windows Desktop performance regression affecting multiple users. |
|
While many of those issues seem to specifically focus on windows; a lot of them seem to also correlate with similar sorts of performance issues on macOS as well; so I don't think this is just a 'Codex on Windows' performance problem; but more of a 'Codex performance problem' in general. |
|
Nah, I have a Mac as well, and the specific issue I am reporting is not happening on my Mac but is happening on my two other Windows machines. There is a real issue with the Windows OS right now that started after June 12th. |
|
Codex Desktop on Windows appears to have a Git/workspace probing loop that can repeatedly spawn git.exe, conhost.exe, and sometimes powershell.exe. This is not only a CPU/Defender scanning issue: on my machine it also caused continuous Windows kernel paged-pool growth under nt!se security-token tags, especially Toke, SeTd, SeDt, SeTl, and SeAt. In one xperf trace window of about 65 seconds, I captured 2,363 git.exe process records, with 1,182 of them parented by Codex.exe. Another reproduction window of about 41 seconds captured 1,144 git.exe, 628 conhost.exe, and 56 powershell.exe, again with the largest parent being Codex.exe. The stack repeatedly showed: Codex.exe / chrome.dll PoolMon/PoolMonX showed sustained growth in these tags. For example, Toke grew from Diff 222,869 / 403,878 KB to Diff 626,608 / 1,135,644 KB, with SeTd, SeDt, SeTl, and SeAt growing in sync. This was not a normal per-process handle leak; process handle counts looked normal, while kernel pool tags under nt!se continued increasing. The strongest reproduction path was a Codex Desktop workspace root that contained multiple project folders. Codex repeatedly touched or recreated an empty .git directory in the workspace root, then its background Git probing repeatedly launched Git to determine repository/root/origin information. Removing/renaming the empty .git and moving Codex away from that multi-repository parent workspace stopped the active growth. Later testing suggests this may also happen in both valid Git workspaces and newly isolated non-Git workspaces if Codex creates an empty .git directory and then scans it. Expected behavior: Codex should not create host-visible empty .git directories unless it is initializing a real repository. Its Git scanner should ignore malformed/empty .git directories and cache failed repository detection instead of retrying in a tight loop. Background Git probing should also be rate-limited/debounced and should not spawn hundreds or thousands of Git processes per minute. Practical workaround observed: Do not attach Codex Desktop to a multi-repository parent directory as the workspace root. Avoid any empty/malformed .git directory in the workspace root. Use a dedicated workspace directory or a specific project root, and monitor whether Codex recreates an empty .git. Once the Git/process storm stops, the active pool growth stops, but already accumulated kernel pool may require a reboot to fully clear. |
|
Thanks, this is useful context. I tested the Git/workspace-probing theory locally before treating it as my root cause. I found empty malformed I then did a reversible local test:
Result: this did not resolve my lag. After the empty So my current read is:
For clarity: I am not seeing this same issue on my Mac, but I am seeing it on Windows machines. That does not mean macOS performance issues are impossible; it just means the bug I am reporting and testing here is reproducibly Windows-specific for my setup. |
|
Adding one concrete data point from #29187. My case looks like a specific cold thread hydration/resume variant of the broader Windows Desktop performance cluster. During a slow thread switch, Windows showed “Not responding” around ~7s. In the first ~15s, main We also ruled out several local buckets as primary causes: logs DB, sessions folder, generated images, plugin/runtime cache, disposable app/web cache, Efficiency Mode, Defender exclusions, and So this seems aligned with the broader Windows Desktop app/renderer/GPU performance regression pattern, with the most reproducible symptom being cold thread switch/resume followed by instant warm switching. |
|
Chiming in to say for the last month+ I've been having the same exact problem on a high-spec PC. Opening Codex, interacting with it, or it actively doing anything (even in the background with the UI minimized to the system tray) causes severe system input lag. Using Codex via the cli or via VSCode extension (as long as codex desktop is fully closed) does not do this and Codex Desktop on Windows is the only app I have seen this happening in. It is totally tanking my system usability to the point where I basically cannot use Codex desktop. Also worth noting changing the backend the desktop app uses to WSL does not help the issue. Really wish OpenAI would look into this as it makes Codex Desktop on Windows (and Windows as a whole) basically unusable. |
|
I’m seeing this too. |
|
I be honestly I am not a fan of the Codex-App at all - it takes like 1.5gb on the system ssd/harddrive(its ssd in 2026 for all of us, yeah) - and its bigger than I like it to be you can get a very decent expirence using VS-CODE and codex-ide-extension -- I do recomend using codex-ide if you are getting some issue with the codex-app.. and honestly , I dont see why it should be open for people to debug - like the chromium project (which is easy to compile nowadays if you are the proud owner of a cpu in the last 3 years ) as per ddr3 
calculating the,, rtx 5060 vs 4060,, and it being about 30% improvement... What does it tells about server-grade hardware -- if its actually a networking thing (nvlink or whatever) that has improved... you know you can pick up a used exbox for 50$ and have just as much fun... 
|
|
I can reproduce a very similar issue on Windows, and in my case the trigger seems to be the VS Code Codex extension rather than Codex Desktop alone. What I observed:
I also checked WMI activity and the hot WMI host was mainly handling performance-related queries such as:
I tested a couple of other possible suspects on my system, but stopping them did not materially change the WMI CPU usage, while disabling the VS Code Codex extension did. So this may be related to the same broader Windows regression cluster discussed here, but in my setup the most direct trigger is the VS Code Codex extension. |
|
some guy claims even the codex-app is crashing is computer due to the nature of how it built - (but I actually blame Razor+Microsoft-windows-chinese edition) honestly he could enjoy higher stablity if he used linux-(fedora is great for out of the box driver support) as per linux-support, I think you can just use the codex (/goal Use this MacOS port in codex-app and port the way its built for MacOs-And-Windows, its not that easy - make sure you follow the same guildlins and support that was given to codex-rs-cli in terms of sandboxing or whatever) I also think its a good interduction for some new employee or whatever (just make sure they dont make heavy use of the vibe coding tools -- so they actually learn the code base) 
|
|
Thanks for the recommendation. I've actually been considering trying out a Linux system. |
|
you wont regret it just make sure you dont use GNOME , (as its not fit for most people) i recomend using KDE/plasma and if you make the switch I also recomend uninstall gnome (if you decide to use kde plasma) just make sure you use the wiki kde- should be install over sddm (but doesnt really matter nowadays - a lot has improved but its recomended ,, do to the recent change from xorg to wayland) fun fact I think people natrually dislike linux because of the lack of VSYNC support that it didnt had for many years giving it a weird feel and vibe https://fedoraproject.org/wiki/KDE do not use arch-linux under any use case - your system will breack with arch-linux as they like to break things often - and I dont want you to not be able to boot in into your machine - because of some vibe coder |
|
Codex updated today to merge with the ChatGPT app and add GPT 5.6. Chiming in here to say that, somehow, despite multiple people having this issue, the app is still causing massive system-wide performance problems. Genuinely don't know how this isn't a higher priority given the desktop app is basically unusable for many of us, which is becoming increasingly more frustrating. You can give it a fresh coat of paint all you want but it's kinda meaningless if the app isn't even usable. Specs for reference: Processor: AMD Ryzen 9 9950X3D 16-Core Processor (4.30 GHz)
Storage: 5.98 TB of 10.01 TB used (System drive: 2TB NVMe SSD) I can tolerate slowdowns in-app that are isolated to the app, but the fact that this thing is managing to freeze input across my entire system making it borderline impossible to use my system while codex is doing anything is mind blowing to me. Like how does something in what should be a simple app mess up that hard??? |
|
good hardware doesnt buy preformance at some level -- you would have the same user expiremece with a second hand notebook but I understand I like video games too , I usally play at low settings -- I got a beast of a computer I got a used RTX 3080 , and 16gb ddr4 ram , I run any game I want at 1080p at 100fps+ including modern tripple AAA games . the used card actually cost me $330 - it was running even better, after I reapplied thermal paste into the card itself I run any tripple a game I want, at medium settings or low settings (I also have a gtx970 machine , which runs any game at low settings at 60fps easy including the modern ones , if I set the screen the 720p ---- which is standard , just put the screen more away from you its the same sharpness - you get from 1080p ) but again, its not a great expeness , in a few years from now you can end up losing all of your teeth and end up paying 50K$ for a all-on-4 surgery.... in many places in the world they dont offer it -- despite being a good solution --- over all cost/reward -- speaking as the cost of life and being able to chew again -- and those last 20+ years to a lifetime --- so better get yourself implants and cheaper things (betting on the idea you might die sooner than you think to not over spend on something , so about age 50 - you should consider it ) |
|
I can confirm this exact failure mode on Windows 11 with Codex Desktop. I captured the behavior with Process Monitor. Codex created an empty The creation event was:
After that, the same capture showed repeated access to the empty These 5,131 events occurred in just 74.4 seconds. They included 1,945 events from git.exe and 1,746 from codex.exe. Could Codex avoid creating host-visible empty |
|
You can speed up thread loading by deleting the .git folder, but Codex will eventually add it back. I'll have to try again, but from memory this problem only explains part of the performance issue. |
|
Figured I'd send this here for anyone that wants to try it. Had GPT 5.6 Sol on Ultra take a crack at figuring out the exact issue and how to fix it. Ended up making a patched version of the Codex (now ChatGPT) desktop app that is currently working without issues. Here's the writeup it did for the issue and what it changed to fix it: SummaryCodex Desktop for Windows caused intermittent system-wide input stalls whenever the app was open, especially during active command execution. Mouse and keyboard delivery stalled in unrelated Windows applications as well as inside Codex. With Desktop fully closed, equivalent Codex work through the CLI or VS Code did not independently reproduce the problem. The affected Microsoft Store package was Inspection of the packaged Electron application found two Desktop-generated process-storm families:
The most important finding was a command-lifecycle path inside the chat-process registry. Its An isolated, repacked copy of the application was modified to suppress the routine Git and WMI discovery paths while leaving the Microsoft Store installation untouched. In the strongest controlled WMI A/B:
This is direct intervention evidence that the Desktop application’s own process-discovery work contributed materially to the system-wide input stalls. User-visible behavior
No display, GPU, chipset, power, input-device, or global Windows setting was changed as part of the successful diagnostic intervention. The behavior changed after modifying only code inside a copied Desktop runtime. Root cause1. Telemetry process snapshot workerThe bundled file: performed system-wide process and performance inventory through fresh PowerShell processes. Its query families included: Get-CimInstance Win32_Process |
Select-Object ProcessId, ParentProcessId |
ConvertTo-Json -Depth 2and: $cpuByPid = @{}
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process |
ForEach-Object { $cpuByPid[[int]$_.IDProcess] = [double]$_.PercentProcessorTime }
Get-CimInstance Win32_ProcessEach sample created a new 2. Shared process-manager snapshotThe bundled shared module: contained a separate Windows process-manager implementation. In this build, the shared snapshot function was exported as One 20-second active-use capture recorded:
This path was independent of the telemetry worker and could perform the same kind of global PowerShell/WMI inventory. 3. Chat-process registry command-lifecycle pathThe same module exported the chat-process registry class as For a command item without a known OS PID, the registry retried discovery at approximately: A single registry mutation could therefore perform several global scans. The mutation could occur when a command started and again when it completed, making active command traffic a direct trigger for repeated WMI work. 4. Automatic repository-origin discoveryThe Desktop sidebar also requested repository-origin metadata for many known working directories. The Git worker resolved directories concurrently and launched command families such as: This produced hundreds of short-lived Git and console-host processes during launch and project refresh. It was a separate contributor to process churn, although the private registry WMI path had the clearest direct input-latency A/B. Why an application-local defect affected the whole systemThe defect did not merely make the Codex window slow. It repeatedly created system-wide work:
That work competed with input delivery and unrelated foreground applications. The low-level input probe measured the resulting delay at the Windows hook-delivery boundary, confirming that the symptom existed outside the app’s renderer. Fix appliedIsolated copied runtimeThe Microsoft Store package was not modified. Its application payload was copied into a separate user-writable, versioned runtime. The Electron Native modules remained outside the archive in the matching Patch 1: disable the telemetry WMI snapshotThe replacement parentPort.postMessage({ type: "ok", value: [] });This prevented the telemetry worker from launching PowerShell/WMI inventory commands. Patch 2: disable automatic Git-origin fan-outThe replacement Conceptually: if (message?.request?.method === "git-origins") {
reply({ type: "ok", value: { origins: [] } });
return;
}
originalListener(message);Patch 3: replace the shared Windows snapshot exportThe original On Windows, export const emptyProcessSnapshot = async () => [];Patch 4: replace the scanning registry mutation methodsThe wrapper exported a subclass of the original registry class. It preserved inherited registry behavior but prevented class NonScanningChatProcessRegistry extends original.rn {
async upsert() {}
async complete() {}
}The wrapper’s Windows-only export behavior was therefore: This was a diagnostic local mitigation, not a proposed production implementation. ValidationWMI process-creation A/BBoth comparison builds used identical non-registry diagnostic settings. The only changed variable was whether registry export A native process-ancestry monitor followed only transitive descendants of the copied Desktop main process for approximately one minute per build:
The registry-suppressed capture contained no Desktop-descendant PowerShell/WMI inventory commands. Input-delivery A/BA short-lived
This probe measured delay up to low-level hook callback delivery, not downstream application rendering. Git process-creation A/BIn matched approximately 47-second controlled launch windows:
The generic launch harness counted machine-wide starts during each window. A separate parent-chain capture confirmed that the large Git burst had Desktop in its ancestry. Tradeoffs and limitations
Recommended upstream fixThe product should preserve the affected functionality without routine global process inventory:
Related public evidence
The public issue is corroborating evidence, not the basis for the local causal finding. The causal conclusion comes from the packaged-code trace and controlled process/input A/B measurements. |
|
Replying here to document that this issue is still relevant as of v26.715 Also confirming the above patch still works. Pretty ridiculous at this point when there's even something GPT itself was able to find to resolve the issue. Something as simple as adding settings to disable the problem sources above would be sufficient to fix this for likely anyone having this problem (which I know is many.) Wish OpenAI could at least weigh in on this or something because right now the only way for me to use the Codex/ChatGPT desktop app on Windows is by having Codex (via the CLI) apply the above patch to a copy of the vanilla app. |
|
good hardware doesnt buy preformance at some level -- you would have the same user expiremece with a second hand notebook but I understand I like video games too , I usally play at low settings -- I got a beast of a computer I got a used RTX 3080 , and 16gb ddr4 ram , I run any game I want at 1080p at 100fps+ including modern tripple AAA games . the used card actually cost me $330 - it was running even better, after I reapplied thermal paste into the card itself I run any tripple a game I want, at medium settings or low settings (I also have a gtx970 machine , which runs any game at low settings at 60fps easy including the modern ones , if I set the screen the 720p ---- which is standard , just put the screen more away from you its the same sharpness - you get from 1080p ) but again, its not a great expeness , in a few years from now you can end up losing all of your teeth and end up paying 50K$ for a all-on-4 surgery.... in many places in the world they dont offer it -- despite being a good solution --- over all cost/reward -- speaking as the cost of life and being able to chew again -- and those last 20+ years to a lifetime --- so better get yourself implants and cheaper things (betting on the idea you might die sooner than you think to not over spend on something , so about age 50 - you should consider it ) |
Uh oh!
There was an error while loading. Please reload this page.
I am posting this as a community/user-impact discussion, not as a replacement for the bug report.
My detailed bug report is here: #28855
The short version: I have been virtually unable to use the Codex Desktop app on Windows since June 12, 2026 because opening/using it causes severe intermittent system input lag. Mouse movement and typing can become visibly delayed. This is not a general laptop performance problem: the same machine handles much heavier work normally, including games and large local projects.
Current machine/app context:
26.616.10790.026.611.8604.0This matters because it has persisted across multiple Codex app updates. The app has received frequent updates, but the Windows Desktop performance problem is still severe enough that I have had to fall back to VS Code / CLI workflows instead of using the Desktop app.
What has already been tried locally:
logs_2.sqlitedatabase so Codex recreated clean logsnode_replMCP config before restartThe original large-log issue was real, but it does not explain the current behavior. After log rotation, the logs stayed small while Codex Desktop/Electron processes still produced CPU bursts and system input lag.
There also appear to be multiple related Windows/Desktop performance reports around the same period:
Some of these are closed or marked as duplicates, while my current issue remains open without a visible maintainer response at the time of posting. I understand duplicate triage is normal, but from a user point of view it is hard to know whether this class of Windows Desktop performance regression is actually being tracked and worked on.
Questions for the Codex team/community:
I am raising this because a high-spec Windows machine should not become difficult to type on just because Codex Desktop is open. If the team needs more diagnostics, I am happy to provide safe/sanitized evidence and can point to the submitted trace/session from the bug report.
All reactions