Codex Desktop on macOS becomes progressively slow and causes system-wide lag during long MCP-heavy sessions #12709

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   mcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers

   on Feb 24, 2026
2. etraut-openai commented on Feb 24, 2026

   

   etraut-openai

   on Feb 24, 2026

   Contributor

   More actions

   Thanks for the bug report. When this occurs, do you see heavy CPU utilization? If so, which process is it associated with? I'm wondering whether it's the MCP server, the app, or some other process.

   Are you pretty confident that the issue is correlated with MCP usage? We've had other reports of this happening when threads become very long.
3. salleizarg commented on Feb 24, 2026

   

   salleizarg

   on Feb 24, 2026

   Author

   More actions

   Thanks for the bug report. When this occurs, do you see heavy CPU utilization? If so, which process is it associated with? I'm wondering whether it's the MCP server, the app, or some other process.

   Are you pretty confident that the issue is correlated with MCP usage? We've had other reports of this happening when threads become very long.

   That's a good question - I tested and no longer think MCP is the problem here. What I can say so far:

   • The slowdown is in all threads, but it's specifically worse in longer threads and more impactful on the system for sure.
   • However, codex helper (renderer) has gone up to 163% cpu usage from simply switching threads (even shorter ones); not certain what is the root cause between thread size/rendering/state growth. Especially since that happens from simply switching to a different thread in a different project. UI is notably unstable.
   • In practice, restarting Codex or starting a new thread temporarily fixes the problem.

   
4. minured commented on Apr 15, 2026

   

   minured

   on Apr 15, 2026

   More actions

   same, when I switch to codex interface, my gpu up to 100%
5. jeffersonlicet commented on Apr 16, 2026

   

   jeffersonlicet

   on Apr 16, 2026

   More actions

   Same here, its unusable

   👍React with 👍2Reacted by Daniil Baunov and Luca
6. ambrosino-oai

   added

   performance

   on May 4, 2026
7. baunov commented on May 7, 2026

   

   baunov

   on May 7, 2026

   More actions

   Same. Even spinners are rendered at like 3FPS. Not usable. Any solution so far?
8. gongqij commented on May 26, 2026

   

   gongqij

   on May 26, 2026 – with ChatGPT Codex Connector

   More actions

   I am seeing a very similar issue on an Intel Mac, with one additional signal that may help narrow this down.

   Environment

   • App: Codex Desktop
   • Hardware: MacBook Pro 16-inch, 2019
   • CPU architecture: Intel / x86_64
   • GPU: AMD discrete GPU
   • Machine age: about 5 years

   What happens

   During normal use, the Mac is responsive. Other apps do not make the whole machine feel slow.

   However, once I start running Codex Desktop on a coding task, the entire system becomes noticeably sluggish:

   • typing becomes delayed
   • app switching and general UI interactions feel laggy
   • the machine feels system-wide slow, not just Codex itself
   • after Codex appears to have produced the final answer, the machine can remain sluggish
   • the only reliable way to recover is to fully quit Codex Desktop with Cmd+Q
   • as soon as Codex quits, the machine becomes responsive again almost immediately

   This makes the issue feel less like general hardware slowness and more like Codex Desktop leaving some background workflow, renderer/compositor activity, app-server state, or cleanup path active after the visible task appears complete.

   Important observation

   In my case, Codex had already answered, but the right-side Progress UI still showed an item spinning.

   So the user-visible answer was complete, but the app did not seem fully idle.

   That seems important because it suggests:

   • final assistant response completion does not necessarily mean the desktop workflow has fully completed
   • some background task or lifecycle state may remain active
   • the app may keep affecting system responsiveness until the whole desktop app is quit

   Local diagnostics observed

   When checking processes, Codex did not appear to be using extreme CPU at that moment. The main Codex-related processes looked relatively quiet:

   • Codex main process: low CPU
   • Codex Helper / Renderer: low CPU at the time of inspection
   • Codex Helper / GPU: low CPU at the time of inspection
   • Codex app-server processes still present

   Memory pressure had improved by the time I checked, but there was evidence of heavy prior memory compression / swap activity. The system still felt laggy until Codex was fully quit.

   The strongest signal is that quitting Codex Desktop immediately restored normal system responsiveness.

   Expected behavior

   Once a task has completed and the final answer is shown, Codex Desktop should fully settle into an idle state.

   The app should not continue causing system-wide UI lag after the visible task appears complete, and the Progress UI should not remain spinning indefinitely unless real work is still running and visible to the user.

   Actual behavior

   Codex Desktop appears to finish the user-visible response, but the app can remain in a state that keeps the whole Mac sluggish. The Progress UI may still show work in progress. Fully quitting Codex Desktop immediately fixes the system-wide lag.

   Why this matters

   On Intel Macs, this makes Codex Desktop difficult to use for real coding work. The user has to treat every completed task as potentially requiring a full app restart, otherwise the whole machine remains degraded.

   This looks related to app lifecycle / workflow cleanup / renderer or app-server idleness rather than simply a slow model response.