Codex: MCP startup failed with 'No such file or directory'

What you see

Starting a session prints a warning like this, usually twice per session:

⚠ MCP client for `node_repl` failed to start: MCP startup failed: No such file or directory (os error 2)

⚠ MCP startup incomplete (failed: node_repl)

os error 2 is the operating system’s way of saying “that path does not exist”. So the message has two halves: an MCP server was configured, and the command it is configured to run could not be found.

Note what the message does not tell you: which executable was missing. That is the main thing the reporters asked to be improved, and it is why the checks below focus on reading the configuration directly.

What it usually means

The client is trying to launch an MCP server over the stdio transport — meaning it runs a local command and talks to it — and the command path in your configuration does not resolve.

Documented causes, in order of how well they are supported by the report:

• A leftover entry pointing at a removed executable. This is the confirmed reproduction. A desktop app installed a private helper executable inside its own application bundle and wrote an MCP entry for it into the shared Codex configuration. When the app was uninstalled, the executable went away but the configuration entry stayed. Every new CLI session then tried to launch a file that no longer existed.
• An upgrade rewriting the entry. One reporter said the entries came back after they upgraded Codex, after they had already removed them. If you remove an entry and it reappears, something is regenerating it.
• A genuinely missing dependency. If an MCP server relies on a runtime that is not installed or not on PATH, you get the same class of error.

This is not necessarily a broken Codex installation. In the reported cases the session still started and stayed usable — the cost was a repeated warning and one unavailable MCP server.

Quick checks

1. Read the warning carefully. The client name in backticks is the key to look up in your configuration.
2. Find the matching configuration block. MCP servers are configured as tables under a mcp_servers prefix, so search your Codex configuration file for that client name.
3. Look at the command value in that block. Is it a path inside an application bundle or a folder for an app you have since removed or moved?
4. Check that the path exists. If the configured path is inside an uninstalled application, this guide applies directly.

Fixes, by branch

If the configured path no longer exists

1. Back up your Codex configuration file so you can restore it if you remove too much.
2. Locate the block for the failing client and read its command value.
3. Confirm the path is gone. If it points inside an application bundle you have removed, the entry is stale.
4. Remove or disable that block. Removing the whole block is what the reporters did; if your configuration syntax supports disabling a server without deleting it, that is the less destructive option. Choose one, and do not leave the block half-edited.
5. Start a new session and check whether the warning is gone.

If you still want that MCP server, install it properly so that its command exists at a path you control, then re-add the entry pointing at the new location.

If the entry keeps coming back

• Note which version you are on when it reappears. The report includes a case where the entries were recreated after an upgrade.
• Check whether a desktop app is still installed and writing the entry. If the app is installed, the helper may genuinely be there and something else is wrong.
• Re-check after upgrades rather than assuming a one-time fix held.

If the path exists and you still get os error 2

• Check the file’s execute permission. A file that exists but is not executable can surface as a launch failure.
• Check that the path is absolute. A relative command depends on the working directory the client launches from.
• Confirm the shebang or interpreter the file expects actually exists on this machine.

What not to do

• Do not delete your whole Codex configuration directory to silence one warning. The report describes a single stale entry; the corresponding fix is a single stale entry.
• Do not disable the MCP feature globally if you use other MCP servers successfully. You would be removing working functionality to hide one bad entry.
• Do not paste the contents of your configuration file into a public issue without checking it for tokens and environment variables. MCP blocks frequently reference credential environment variables.

How to tell it worked

Start a fresh session and confirm the warning no longer appears, and that any MCP servers you still rely on are still listed as available. A clean start with no warning and no lost functionality is the success criterion.

If it is still failing

If the warning names a client you have never configured, something is writing that entry for you. Find the writer before removing the entry again, otherwise it will return.

Known limits of this guidance

• Evidence level: reported. The reproduction sequence is well documented by the reporters, but this site did not reproduce it.
• The report centres on macOS. The failure class is platform-independent, but the specific stale path in the report is macOS-specific.
• Whether the stale entries should be cleaned up on uninstall is an open request in the report; the checked sources do not show that a fix has shipped.
• If your configuration uses a different transport, such as a URL-based server, this guide does not apply — os error 2 belongs to the launch-the-command path.