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
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 ↗

2 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #26992
  • #28502
  • #28320

Powered by Codex Action

nasadunadu · 1 month ago

I can reproduce the same startup/runtime behavior on a newer macOS Desktop build.

Environment

  • macOS (Apple Silicon)
  • Codex Desktop: 26.707.41301 (build 5103)
  • Renderer: 150.0.7871.115
  • Bundled CLI / app-server: 0.144.0-alpha.4

Sanitized observations

  • mcpServerStatus/list: approximately 10.8-15.6 seconds during Desktop startup/runtime hydration
  • repeated plugin/list: approximately 2-7 seconds per call
  • these calls overlap thread startup/resume and materially increase the time before the UI becomes usable

I explicitly disabled and then removed the bundled Browser, Chrome, Computer Use, Sites, and Visualize plugins, removed all user MCP registrations, and verified that the CLI reported no configured MCP servers. After restarting Desktop, the bundled plugin reconciliation path automatically requested installation of the missing bundled plugins again. Browser was also rewritten from disabled to enabled during reconciliation.

The logs contain repeated bundled_plugin_install_requested, bundled_plugins_reconcile_started, and bundled_plugins_reconcile_completed events. The app also selects Browser/Node runtime paths again even after the explicit local removal.

This makes the documented/configured disabled or removed state non-durable and prevents a reliable lightweight runtime profile.

Expected behavior

  • Disabled or explicitly removed managed plugins should remain inactive across restart, or the UI/config should clearly state that they are mandatory and managed.
  • MCP/plugin discovery should not block unrelated thread rendering or composer readiness.
  • With no user MCPs, status discovery should return quickly and bundled runtime initialization should happen lazily when the capability is first used.

I have omitted local paths, account information, raw logs, and private thread metadata.