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

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.

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.

<img width="1072" height="752" alt="Image" src="https://github.com/user-attachments/assets/020ab8de-9f25-487d-9ea1-014cb6daa631" />

same, when I switch to codex interface, my gpu up to 100%

Same here, its unusable

Same. Even spinners are rendered at like 3FPS. Not usable. Any solution so far?

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.