After the update to Windows 11, the mouse has become noticeably sluggish.
What version of the Codex App are you using (From “About Codex” dialog)?
版本 26.810.41047
What subscription do you have?
plus
What platform is your computer?
x86 win11
What issue are you seeing?
After the update to Windows 11, the mouse has become noticeably sluggish. Below are the troubleshooting results conducted by Codex
Investigation conclusion: The issue is not with the mouse malfunctioning, but primarily due to the sustained high load experienced by Codex after today's update.
I confirm that:
Codex was updated at 13:49 today, and the current version is 26.810.4967.0.
Even without any operations, one of the background tasks still occupies a multiprocessor core for an extended period.
The total memory usage of all Codex components is approximately 2.6GB, with significant fluctuations ranging from 500MB to 900MB.
The log shows that it repeatedly initiates project directory monitoring, with a total of 28 launches, accompanied by multiple status check exceptions. It is highly likely that the monitoring task did not end normally, leading to an increasing operational burden as it continues to run.
The graphics card usage is only about 4% to 6%, and there are no records of graphics card, mouse, or application crashes, so full graphics card usage and mouse malfunction are not the main causes.
There is a "remote viewing" virtual screen driver on the machine, which may amplify the sense of stuttering, but it is not the source of this issue.
After closing Codex, everything returned to normal, which is fully consistent with the aforementioned inspection results.
Therefore, we can confidently conclude that this is a performance issue with today's Codex version, where the project directory monitoring or interface backend task has entered a repetitive loop. Currently, there is no public statement regarding this version in the official documentation, so we cannot be 100% certain about the specific internal function that has gone wrong. However, the source of the problem has been pinpointed to Codex itself.
What steps can reproduce the bug?
Feedback ID: 019fffda-afd0-7f30-92db-175e807f6243
What is the expected behavior?
_No response_
Additional information
_No response_
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Same here. Reported a few minutes ago in Feedback ID no-active-thread-01a00020-5c30-71e0-96dd-181471a1c642
The fact that the lag disappears as soon as Codex exits, while GPU use stays low, matches the recent Windows reports where the expensive work is in Codex's main-process/plugin reconciliation path rather than the mouse/graphics stack itself.
I maintain WinBridge Recovery, which is aimed at Windows Codex Desktop package/cache/runtime inconsistencies. For this case I would not treat it as a generic "repair the app" problem. The useful check is whether the current package and the user-side Chrome/Computer-Use/runtime state are split across versions or repeatedly failing reconciliation. WinBridge checks the installed AppX resources, bundled marketplace/plugin cache,
latest, Native Host and CUA/runtime state separately and only repairs user-owned state when it finds an actual mismatch.If your logs show a healthy, byte-consistent local state and Codex still burns a core while idle, that is evidence for an upstream 26.810 performance regression and WinBridge should stop rather than keep changing files. If you see repeated relocation/cache/native-host errors, though, that local state is within the project's diagnostic scope.
This has been happening a while to be honest...
This is a video of my mouse while codex working.
https://github.com/user-attachments/assets/c29335c2-063f-49be-a39d-20ba9b6755bb