codex - 💡(How to fix) Fix Codex Desktop repeatedly starts full MCP stacks for new sessions/subagents, causing severe slowdown and memory pressure [9 comments, 6 participants]

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.