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
- Install or enable the desktop-managed Codex Security plugin
0.1.20.
- Connect Codex Desktop to a remote Linux project over SSH.
- Use Codex normally.
- Allow active work to finish and leave the desktop/remote app-server running for several hours or overnight.
- Observe the remote
codex app-server consuming more than one CPU core.
- Inspect
logs_2.sqlite or app-server diagnostics.
- Observe repeated
app/list / app/installed activity and repeated -32601 Method not found failures for Codex Security resource discovery.
- Fully disconnect/quit the desktop proxy; CPU load drops.
- 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:
Sanitized logs and additional measurements can be provided if maintainers request them.
What version of Codex is running?
codex-cli 0.144.0-alpha.40.1.20Platform
6.14.11-3-pveWhat 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 proxyreconnected, 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:
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:
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 --stdioCodex Security child processes were present.codex plugin list --jsondid 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-runtimethreads.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:
The process also continuously updated
logs_2.sqlite-walandstate_5.sqlite-wal.Steps to reproduce
0.1.20.codex app-serverconsuming more than one CPU core.logs_2.sqliteor app-server diagnostics.app/list/app/installedactivity and repeated-32601 Method not foundfailures for Codex Security resource discovery.Expected behavior
-32601 Method not foundresponse should be treated as unsupported rather than retried indefinitely.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:
Sanitized logs and additional measurements can be provided if maintainers request them.