codex startup takes very long both in app and cli: mcp list and startup health paths take ~30s even with no user MCPs; desktop app re-adds node_repl after restart
What version of the Codex App are you using (From “About Codex” dialog)?
26.609.71450
What subscription do you have?
plus
What platform is your computer?
Mac: Darwin 25.0.0 arm64 arm
What issue are you seeing?
Note
Issue is present both in CLI and app for mac.
Summary
Codex startup and MCP-related commands are consistently slow on my machine. The most reproducible symptom is that codex mcp list takes about 30 seconds even when there are no user-configured MCP servers. After restarting the desktop app, Codex also re-adds a node_repl MCP block to ~/.codex/config.toml, apparently through the built-in Browser/Chrome plugin path.
This makes startup feel slow in both desktop and terminal workflows, and it is hard to disable because the app rehydrates part of the MCP config after restart.
Environment
- macOS:
Mac OS 26.0.1,macos-aarch64 - CLI from npm:
codex-cli 0.140.0 - Desktop app bundled CLI:
codex-cli 0.140.0-alpha.2 - Codex app path:
/Applications/Codex.app/Contents/Resources/codex - Date observed:
2026-06-16
What steps can reproduce the bug?
Reproduction for CLI
- Start with
~/.codex/config.tomlcontaining no custom MCP servers. - Disable startup update checks:
check_for_update_on_startup = false
- Disable the bundled Computer Use plugin:
[plugins."computer-use@openai-bundled"]
enabled = false
- Confirm no custom MCP blocks are present:
rg -n "\\[mcp_servers|context7|chrome-devtools" ~/.codex/config.toml
- Run:
time codex mcp list
Reproduction for App
Start the app, wait forever.
What is the expected behavior?
Actual behavior
Even with no user MCP servers configured, codex mcp list takes about 30 seconds:
No MCP servers configured yet. Try `codex mcp add my-tool -- my-command`.
codex mcp list 0.05s user 0.04s system 0% cpu 30.099 total
The same ~30s behavior occurs with both binaries:
time /Users/alejandrocamus/.nvm/versions/node/v24.15.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/bin/codex mcp list
time /Applications/Codex.app/Contents/Resources/codex mcp list
Both return after about 30.07s.
By contrast, trivial CLI paths are fast:
codex --version ~0.06s
codex --help ~0.05s
After restarting the desktop app, Codex re-adds this MCP block to ~/.codex/config.toml:
[mcp_servers.node_repl]
args = []
command = "/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl"
startup_timeout_sec = 120
The desktop app also starts helper processes related to built-in browser tooling:
/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl
/Users/.../.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/...
Expected behavior
codex mcp listshould return immediately when no MCP servers are configured.- If MCP/plugin status discovery is slow or unavailable, it should not block unrelated startup or basic listing paths for ~30 seconds.
- If the desktop app re-adds built-in MCP entries, there should be a clear supported way to disable this behavior.
Additional information
Additional Observations
Earlier debugging also found slow desktop startup logs:
Initialize handshake still pendingatdurationMs=10001initialize_handshake_result durationMs=30054 outcome=success- repeated
mcpServerStatus/listcalls around5.9s-7.1s - repeated
plugin/listcalls around1.2s-1.8s
Local state is somewhat large but appears healthy:
~/.codex:2.3G~/.codex/sessions:409M- SQLite integrity checks pass
Workarounds Tried
- Removed custom
context7MCP. - Removed custom
chrome-devtoolsMCP usingnpx -y chrome-devtools-mcp@latest. - Removed
node_replMCP manually. - Disabled
computer-use@openai-bundled. - Set
check_for_update_on_startup = false. - Killed stale
chrome-devtools-mcp,node_repl, and Computer Use helper processes. - Restarted Codex desktop app.
After restart, node_repl was re-added and codex mcp list still took about 30.108s.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗