›_ Codex Issues
Codex Issues / #18333

Codex Desktop repeatedly starts full MCP stacks for new sessions/subagents, causing severe slowdown and memory pressure

Resolved 💬 14 comments Opened Apr 17, 2026 by jianzhangg Closed Apr 24, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.415.21839 (1763)

What subscription do you have?

Paid OpenAI account (exact plan not verified from this session)

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Codex Desktop becomes progressively slower when web-related tasks are used. The send button can keep spinning, sending a message becomes delayed, web actions become much slower over time, and overall memory pressure increases enough that the whole machine feels laggy.

After investigating locally, this does not look like a simple screenshot/token-size issue or only a network/proxy issue. The stronger signal is that the desktop app keeps creating new backend sessions, and each new session or subagent starts a full MCP stack (chrome-devtools, playwright, computer-use) instead of reusing or cleanly disposing existing connections.

I also saw frontend/backend conversation state drift, including repeated Received turn/started for unknown conversation and Conversation state not found messages in the desktop logs.

What steps can reproduce the bug?

  1. Use Codex Desktop on macOS for a while with web/MCP tools enabled.
  2. Perform normal work that includes browser-related tasks, and keep using the app across multiple conversations.
  3. Let background subagent work happen as well; in my case hidden memory_consolidation threads were created automatically.
  4. Observe that the same app-server process can stay alive while new sessions keep being initialized.
  5. In logs, new sessions repeatedly run session_init.mcp_manager_init(enabled_mcp_server_count=3), including subagent sessions (is_subagent=true), which means a full MCP stack is started again.
  6. Over time, process count and RSS keep climbing, and the UI becomes sluggish.

Concrete evidence from this machine:

  • Hidden threads in local state DB with source={"subagent":"memory_consolidation"} were created at 2026-04-17 16:56:50 and 2026-04-17 17:53:57.
  • Those timestamps aligned with fresh MCP batches starting.
  • Frontend logs showed thread/unsubscribe and then shortly after thread/read / thread/resume for the same conversation.

What is the expected behavior?

The desktop app should reuse existing MCP connections when possible, or reliably close previous per-session MCP stacks when they are no longer needed.

Background subagents such as memory consolidation should not start a full browser/MCP stack unless that work explicitly requires it.

Frontend and backend conversation/session state should stay consistent so the app does not keep receiving events for unknown conversations.

Additional information

Additional evidence from local investigation:

  • Desktop app version: 26.415.21839 (1763)
  • app-server observed on 2026-04-17: 0.122.0-alpha.1
  • Similar symptoms were already present on 2026-04-16 with 0.119.0-alpha.28, so the 2026-04-17 release may have amplified the problem but does not appear to be the sole root cause.
  • Resource usage at the time of investigation:
  • about 50 chrome-devtools related processes, about 1.28 GB RSS total
  • about 38 playwright related processes, about 745 MB RSS total
  • about 14 computer-use related processes, about 117 MB RSS total
  • app-server itself was only about 113 MB RSS
  • One hidden memory_consolidation thread showed prompt_length=66651, with transport log entries around 147 KB to 345 KB.
  • Another hidden memory_consolidation thread had transport log entries around 417 KB to 553 KB.

The key concern is not just that the app is slow, but that hidden/background activity appears to repeatedly initialize full MCP stacks and then leave the frontend and backend conversation state out of sync.

If useful, I can provide the relevant local log excerpts from the desktop log, ~/.codex/log/codex-tui.log, and the local state/log SQLite databases.

View original on GitHub ↗

14 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #17574
  • #17832
  • #17115
  • #16895

Powered by Codex Action

ciuchka2222 · 3 months ago

Same here. Started immediately after updating to the latest version mentioned in this issue.

Same machine, same setup, same workload. Yesterday it was fine. Today Codex is much more sluggish, with higher memory pressure / swap and heavier Codex Helper / Renderer usage on macOS.

digows · 3 months ago

Same, it was perfect before this last one.

rafaself · 3 months ago

Same here, but I just ran a simple prompt and huge background tasks consumed almost all of the limits. #18358

The rollouts after 11:59 were triggered after a simple task and consumed a lot of tokens

<img width="918" height="74" alt="Image" src="https://github.com/user-attachments/assets/546991a9-986c-4778-98e4-4219b60a3324" />

rafaself · 3 months ago

It seems related to some memory management by codex

digows · 3 months ago

Also, as @rafaself mentioned, token usage increased significantly.
I've never touched my daily limits until today.

rafaself · 3 months ago

I turned off the memories feature and this issue apparently has gone. So it's probably what was described in #18358

https://developers.openai.com/codex/memories

geodan4ik · 3 months ago

same here, suddenly started hitting daily limits and sending a simple "hello" message just keeps the wheel spinning for good 5-7 seconds before it sends the message

rafaself · 3 months ago
same here, suddenly started hitting daily limits and sending a simple "hello" message just keeps the wheel spinning for good 5-7 seconds before it sends the message

Memories was turned on in the config.toml, since I toke it out, this issue didn't happened again.

geodan4ik · 3 months ago
> same here, suddenly started hitting daily limits and sending a simple "hello" message just keeps the wheel spinning for good 5-7 seconds before it sends the message Memories was turned on in the config.toml, since I toke it out, this issue didn't happened again.

I dont have "memories" / "memory" in my config.toml

0xWinner98 · 3 months ago

Still reproducible on macOS with a newer 26.415 build.

Environment

  • Codex App: 26.415.32059 (1789)
  • Platform: macOS

User-facing symptom

The desktop app is slow to submit messages. The send button keeps spinning for a long time before the message appears / starts processing.

Local evidence from this machine

I checked recent desktop logs and current child processes.

Repeated slow model/list and thread/resume in desktop logs

Examples from Apr 17–18 local time:

  • 2026-04-17 08:51:21 — method=model/list durationMs=4872
  • 2026-04-17 08:51:23 — method=thread/resume durationMs=4007
  • 2026-04-17 09:26:52 — method=model/list durationMs=5007
  • 2026-04-17 09:26:55 — method=thread/resume durationMs=5203
  • 2026-04-18 08:14:22 — method=model/list durationMs=3147
  • 2026-04-18 09:17:23 — method=model/list durationMs=2320
  • 2026-04-18 10:44:45 — method=model/list durationMs=2014
  • 2026-04-18 07:58:13 — method=thread/resume durationMs=738
  • 2026-04-18 09:50:30 — method=thread/resume durationMs=436

These are from the desktop logs under ~/Library/Logs/com.openai.codex/2026/04/17 and ~/Library/Logs/com.openai.codex/2026/04/18.

Current child-process state while the app is open

At the time of inspection:

  • Codex app PID: 59602
  • codex app-server PID: 59655
  • Codex Helper (Renderer) RSS: about 322.8 MB
  • SkyComputerUseClient mcp children under app-server: 12 processes, about 97.8 MB RSS total

Representative examples:

  • PID 59786 — SkyComputerUseClient mcp
  • PID 59866 — SkyComputerUseClient mcp
  • PID 60113 — SkyComputerUseClient mcp
  • PID 60240 — SkyComputerUseClient mcp
  • PID 64933 — SkyComputerUseClient mcp

Transport-related note

I searched the Apr 17–18 desktop logs for these strings:

  • Falling back from WebSockets to HTTPS transport
  • stream disconnected before completion
  • Reconnecting...
  • invalid_workspace_selected

That search returned no hits on this machine, so the local evidence here points more strongly to desktop/app-server responsiveness and helper-process buildup.

ciuchka2222 · 3 months ago

Fixed

itselavia · 2 months ago

Local corroboration for the computer-use side of this issue on macOS desktop.

Observed under one long-lived codex app-server (PID 46990):

  • 50 direct child SkyComputerUseClient mcp processes
  • family RSS: 661.4 MB
  • every client had 0 descendants
  • all were direct children of the app-server, not a separate daemon/service

Stale rule used:

  • process state starts with S
  • ETIME > 60m

Split at the time of capture:

  • stale: 44, 559.0 MB RSS
  • fresh/current-session: 6, 102.5 MB RSS

Representative ps snapshot:

15349 46990 15.8MB 01-04:23:04 S ./Codex Computer Use.app/.../SkyComputerUseClient mcp
60747 46990 19.2MB    13:08:31 S ./Codex Computer Use.app/.../SkyComputerUseClient mcp
94605 46990 16.4MB       22:00 S ./Codex Computer Use.app/.../SkyComputerUseClient mcp
96515 46990 16.8MB       21:20 S ./Codex Computer Use.app/.../SkyComputerUseClient mcp

Stale and fresh instances had the same lsof shape:

  • binary under ~/.codex/plugins/cache/openai-bundled/computer-use/1.0.755
  • only stdio pipes on 0/1/2
  • one handle to ~/Library/Group Containers/2DC432GLL2.com.openai.sky.CUAService/.../Analytics.db
  • one netsrc control handle
  • no child processes
  • no obvious extra active sockets

After killing only the stale set:

  • SkyComputerUseClient mcp: 50 -> 6
  • family RSS: 661.4 MB -> 102.5 MB
  • all 44 stale clients exited on SIGTERM

This matches the session/subagent lifecycle failure described here:

  • computer-use is being instantiated as a per-session helper client, not as one shared singleton
  • old clients are not being reaped when their owning session disappears
  • the active floor after stale-only cleanup remained 6 current-session clients, which is consistent with multiple live session/subagent stacks existing at once

At the same time, the same app-server also had 6 fresh duckduckgo-mcp-server helper roots. So the desktop symptom looks like “one helper batch per live session/subagent, old batches not reaped,” not a standalone computer-use binary bug.

This looks like the desktop manifestation of the broader teardown / manager-replacement problem discussed in #18881, but it belongs here because computer-use is part of the repeated full MCP stack this issue calls out.

jif-oai contributor · 2 months ago

This will get fixed thanks!