[Linux remote app-server] Sustained idle CPU from Codex Security MCP resource-list retry loop

Start with the remote codex app-server and its MCP resource-discovery path, using the repeated app/list and app/installed traffic plus the -32601 Method not found messages as the first signals. Compare behavior with the Codex Security plugin enabled and after disconnecting the desktop proxy. Done means an idle remote app-server stays near zero CPU, unsupported MCP methods are not retried indefinitely, and refresh activity is bounded with backoff.

What version of Codex is running?

• Codex app-server / CLI: codex-cli 0.144.0-alpha.4
• Codex Security plugin bundle: 0.1.20
• Surface: Codex desktop app connected to a remote Linux project over SSH
• Desktop app version: not captured

Platform

• Debian GNU/Linux 13 (trixie), x86_64
• Linux kernel 6.14.11-3-pve
• 4 logical CPUs

What issue are you seeing?

A long-lived remote codex app-server --listen unix:// process consumes approximately 1.2–1.3 CPU cores after user work has finished and the machine is expected to be idle. The condition recurs after using Codex and leaving it overnight, causing the host fans to run continuously.

Fully quitting/killing the visible/local Codex processes temporarily stopped the load, but the remote app-server survived. When a new desktop codex app-server proxy reconnected, the same backend PID resumed the high-CPU behavior.

The strongest recurring log signature is an MCP capability/retry loop involving the desktop-managed Codex Security plugin:

Failed to list resources for MCP server 'codex-security':
Mcp error: -32601: Method not found

Failed to list resource templates for MCP server 'codex-security':
Mcp error: -32601: Method not found

Those two warnings repeat roughly every 3–5 seconds. The Codex Security MCP bundle contains tools but does not appear to implement resource or resource-template handlers.

At the same time, the app-server repeatedly processes installed-app refresh traffic. In one 30-second log window for the affected process:

codex_http_client::custom_ca                 INFO   223 records
codex_app_server::outgoing_message          TRACE  130 records
rmcp::service                               TRACE  107 records
codex_app_server::message_processor         TRACE  104 records
hyper_util::client::legacy::pool            TRACE  105 records

records containing app/list:                 129
records containing app/installed:             66

No user logging override was enabled: RUST_LOG, CODEX_LOG, and related settings were unset, and no logging/trace option was present in ~/.codex/config.toml.

Two node ./mcp/server.mjs --stdio Codex Security child processes were present. codex plugin list --json did not list Codex Security, so this appears to be a desktop-managed remote plugin rather than a CLI-managed plugin.

CPU and process observations

A settled 15-second per-thread sample repeatedly showed about 120–130% aggregate CPU across several tokio-runtime threads.

The app-server thread count increased from 29 during the first daily observation to 57 on the following day. This may indicate accumulated per-thread/MCP state, although a thread leak has not been proven.

A separate 3-second I/O sample during the loop showed approximately:

• 18 MB read through ~16,000 read syscalls
• 2 MB written through ~1,650 write syscalls

The process also continuously updated logs_2.sqlite-wal and state_5.sqlite-wal.

Steps to reproduce

1. Install or enable the desktop-managed Codex Security plugin 0.1.20.
2. Connect Codex Desktop to a remote Linux project over SSH.
3. Use Codex normally.
4. Allow active work to finish and leave the desktop/remote app-server running for several hours or overnight.
5. Observe the remote codex app-server consuming more than one CPU core.
6. Inspect logs_2.sqlite or app-server diagnostics.
7. Observe repeated app/list / app/installed activity and repeated -32601 Method not found failures for Codex Security resource discovery.
8. Fully disconnect/quit the desktop proxy; CPU load drops.
9. Reconnect; the condition eventually resumes against the same long-lived backend.

Expected behavior

• An idle app-server should return close to zero CPU.
• MCP capability negotiation should avoid calling methods the server does not advertise.
• A -32601 Method not found response should be treated as unsupported rather than retried indefinitely.
• Installed-app and resource discovery refreshes should be bounded and use backoff.
• Per-thread/MCP resources should not accumulate across completed or inactive conversations.
• A disconnected remote app-server should remain idle.

Additional information

The symptom reproduced on two consecutive mornings. Restarting visible Codex processes was only a temporary mitigation because the remote backend remained alive.

Potentially related but not exact duplicates:

• #17320 — excessive SQLite WAL writes from persisted TRACE logs
• #35485 — per-thread MCP child processes not reaped
• #38820 — desktop/plugin app-server CPU behavior

Sanitized logs and additional measurements can be provided if maintainers request them.