Codex Desktop repeatedly sends full mcpServerStatus/list, restarts MCP helpers, and causes sustained high CPU

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

Codex Desktop client: 26.730.61639, Desktop packaging: unofficial ilysenko/codex-desktop-linux port

What subscription do you have?

ChatGPT Plus

What platform is your computer?

OS: TUXEDO OS / Linux x86_64

What issue are you seeing?

I am running Codex Desktop through the unofficial ilysenko/codex-desktop-linux port on Linux. The Codex CLI on the same machine does not exhibit the problem.

After switching to/using Codex mode in Codex Desktop, the native
Codex app-server continuously consumes roughly 130–190% CPU.

The equivalent Codex CLI session remains essentially idle.

While Desktop is otherwise idle, the app-server repeatedly creates
node_repl and codex-computer-use-linux MCP helpers. They initialize
successfully, are terminated after roughly 1–2 seconds, and are
recreated every few seconds.

A wire-level strace of app-server stdin repeatedly captures:

{"method":"mcpServerStatus/list",
"params":{"cursor":null,"limit":100,"detail":"full"}}

There is no threadId in these repeating requests.

Separately, strace shows the Codex app-server explicitly terminating
the MCP helper process groups:

kill(-<node_repl_pid>, SIGTERM) = 0
kill(-<computer-use_pid>, SIGTERM) = 0

App-server logs correspondingly report the MCP services as cancelled
and the child processes exiting with SIGTERM.

What steps can reproduce the bug?

1. Launch Codex Desktop on Linux using the unofficial ilysenko/codex-desktop-linux port.

2. Open any Codex conversation / enter Codex mode. No active task is required; the issue continues while the Desktop app is otherwise idle.

3. Observe the native Codex app-server process, for example with:

   ps -eo pid,ppid,%cpu,cmd | grep -E 'codex.*app-server|node_repl|computer-use'

4. The app-server begins consuming sustained high CPU, typically around 130–190% on my machine.

5. Observe its child processes over several seconds. node_repl and codex-computer-use-linux mcp are repeatedly started, terminated after roughly 1–2 seconds, and recreated every few seconds.

6. A trace of app-server stdin shows repeated global requests of the form:

   {"method":"mcpServerStatus/list",
   "params":{"cursor":null,"limit":100,"detail":"full"}}

   These requests occur repeatedly even while the UI is idle.

7. For comparison, run Codex CLI on the same machine. The CLI and its corresponding MCP helpers remain essentially idle and do not exhibit the repeated start/terminate cycle.

Expected result:
Codex Desktop should remain close to idle CPU usage when no work is being performed, and MCP helper processes should not be continuously terminated and respawned.

Actual result:
The Desktop app-server repeatedly performs full MCP status discovery, tears down the MCP services, and recreates them, causing sustained high CPU usage.

What is the expected behavior?

An idle Codex Desktop instance should not repeatedly initialize and
tear down its MCP servers as a consequence of MCP status queries.

In particular, persistent stdio MCP helpers should not be continuously
SIGTERM'd and respawned while the application is idle.

Additional information

The generated app-server protocol exposes:

• detail = "full"
• detail = "toolsAndAuthOnly"

The Desktop bundle contains code using toolsAndAuthOnly in some status
paths, while the problematic global requests observed on the wire use
detail:"full".

It may be worth checking whether the repeatedly polled status path
should use the lighter detail level, cache/reuse MCP state, or avoid
repeatedly constructing and destroying MCP connections.

Start by tracing the Codex app-server handling of the repeated mcpServerStatus/list requests and the MCP helper lifecycle. Compare the full and toolsAndAuthOnly status paths described in the issue, using stdin tracing and process observations to confirm the request and restart cycle. Done means an idle Desktop session no longer repeatedly polls, terminates, and respawns MCP helpers or sustains high CPU.