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

Open 💬 2 comments Opened Jun 16, 2026 by arjuna-dev

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

  1. Start with ~/.codex/config.toml containing no custom MCP servers.
  2. Disable startup update checks:
check_for_update_on_startup = false
  1. Disable the bundled Computer Use plugin:
[plugins."computer-use@openai-bundled"]
enabled = false
  1. Confirm no custom MCP blocks are present:
rg -n "\\[mcp_servers|context7|chrome-devtools" ~/.codex/config.toml
  1. 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 list should 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 pending at durationMs=10001
  • initialize_handshake_result durationMs=30054 outcome=success
  • repeated mcpServerStatus/list calls around 5.9s-7.1s
  • repeated plugin/list calls around 1.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 context7 MCP.
  • Removed custom chrome-devtools MCP using npx -y chrome-devtools-mcp@latest.
  • Removed node_repl MCP 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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗