Local MCP servers broken?

Resolved 💬 10 comments Opened Oct 17, 2025 by croqaz Closed Oct 18, 2025

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.46.0

What subscription do you have?

enterprise

Which model were you using?

gpt-5-codex

What platform is your computer?

Linux 6.17.3-2-cachyos x86_64 unknown

What issue are you seeing?

Hi. I can't make the local MCP servers work at all with Codex.
I tried both reference MCP servers from Python and Typescript.

What steps can reproduce the bug?

These are the MCP servers that I used: https://gist.github.com/croqaz/dfccc9c1cf5c9841428fd9f0c44f6014
Again, they are just the standard ones from Python or Typescript.

What is the expected behavior?

Should use the local MCP servers.

Additional information

This is my config:

[model_providers.openai]
name = "OpenAI"
base_url = "https://api.openai.com/v1"
env_key = "OPENAI_API_KEY"

[mcp_servers.mcp1]
command = "uv"
args = ["run", "mcp", "run", "server.py"]
cwd = "/mcp1"

[mcp_servers.mcp2]
command = "npx"
args = ["-y", "tsx", "server.ts"]
cwd = "/mcp2"

This is MCP1 -- it is started on STDIO but I'm just showing that it can run as a local server, it's a working server:

This is MCP2 -- converted from a local HTTP server and it works:

This is Codex CLI, which doesn't see any of the MCP servers:

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 9 months ago

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

#5161
#5208
#5044
#4400

Powered by Codex Action

croqaz · 9 months ago

I tried RUST_LOG=codex_core=debug,codex_tui=debug ENV but I don't see anything extra in the session logs, so I have no idea how is Codex trying to connect and what is failing.

Please let me know if I can enable some traceback that is useful, but anyway, I shared both MCP servers above and it should be very easy to reproduce.

gpeal contributor · 9 months ago

Can you try with 0.47? cwd was released in 0.47?

https://github.com/openai/codex/pull/5246

synestiqx · 9 months ago

@croqaz It’s a synchronization issue. I once sent a PR with a fix and reactive loading.

Try running:

npx @playwright/mcp@latest --browser=chromium

(or another MCP) in your terminal.
Wait a moment before starting Codex — then it should work.

And what I wrote has been tested and works.

The timeout mechanism fails quite often in such cases.
It would be much more convenient if MCP loaded reactively.

gpeal contributor · 9 months ago

@croqaz It’s a synchronization issue. I once sent a PR with a fix and reactive loading. Try running: npx @playwright/mcp@latest --browser=chromium (or another MCP) in your terminal. Wait a moment before starting Codex — then it should work. And what I wrote has been tested and works. The timeout mechanism fails quite often in such cases. It would be much more convenient if MCP loaded reactively.

This sounds like an issue with the Chrome MCP. All Codex can do is issue tool calls to it using the schema that it exposes and, from what I can tell, that is working. If there is something more specific you think Codex should be doing that differs from other agent harnesses, feel free to reopen.

synestiqx · 9 months ago

@gpeal
I have no idea at what point this started to sound like a Chrome issue :).
Context7 and any other MCP will behave exactly the same.
This has nothing to do with Chrome. I honestly don’t understand where that idea or assumption came from, but okay :)

I clearly wrote that the problem lies in the synchronization between the MCP startup and Codex.
That’s why calling any MCP beforehand—before launching Codex—makes it fit within the loading time (it just starts faster the second time).
I also mentioned that reactive loading solves this issue.

If there is something more specific you think Codex should be doing that differs from other agent harnesses, feel free to reopen.

Notice that no other packages wait 30 seconds on startup — they load the MCP reactively.
Claude Code, Droid, etc.

In fact, Codex behaves differently from all the other packages.

So, to put it briefly — the MCP startup timeout isn’t enough.

Do you really think extending it to a minute or two and waiting that long for the program to start is a good solution?
Wouldn’t it be better to handle it reactively in the background instead?

Moreover, I’ve already submitted a PR that fixes this issue — ask @bolinfest about it.
#2968

And doing cwd to the Codex directory won’t help, because Windows requires the use of where to get the full path.
Unix systems use which.
In Rust, which dynamically chooses where on Windows and which on Unix.
The same applies to other Windows-specific aspects, like environment variables, and so on — just saying :)

I sent it over two months ago, I think

That’s why when I say something, it’s usually because I’ve actually tested it myself.
If I haven’t, I make it clear that it’s just my assumption.
Maybe I don’t always phrase things perfectly — my English is at an intermediate level,
so I’m not sure if what I write is always understood the way I intend.
Like with that Chrome thing :)

It just feels strange to me that I submitted a ready solution,
and yet the issue is still full of problems related to it.
I hope I didn’t accidentally offend anyone :)

Best regards and good luck

croqaz · 9 months ago

I can confirm that I was able to connect to the 2 local MCP servers with the new Codex v0.47.0.

It is very UN-intuitive that the error was "request timed out" when the servers are actually starting in 100ms.
I was expecting Codex to error, or warn with something like "unknown param CWD ignored for MCP server mcp1" or a similar message.

This issue had nothing to do with "Chhrome MCP", it was about 2 different MCP servers, one in Python and one in Typescript.

Thank you for the help.

synestiqx · 9 months ago

Unfortunately, it has not been fixed. The error is very clear — it says that the MCP did not load within the designated time.

After the initial run of npx @playwright/mcp@latest --browser=chromium, there are no errors — the tools are working fine.

croqaz · 9 months ago

@AdsQnn your should probably start a new issue, because I already mentioned that issue was about simple local MCP servers, not Playwright. Even if this issue was wrongly renamed.

Your issue is very different than mine. In my case, when I was calling /mcp I couldn't see anything, the local servers were completely broken.
( this was probably because of codex-cli 0.46.0 and the "cwd" option from config )

You seem to have real timeout issues, but the playwright MCP server shows up for you at least. You can actually see the tools like browser_clicks & so on.

synestiqx · 9 months ago

@croqaz
Something completely different? You have exactly the same error — “requested timeout.” But as you wish. I don’t need to open an issue because I’ve already fixed the problem, so I know what it was and clearly described it to help get it resolved.

Your issue is very different than mine. In my case, when I was calling /mcp I couldn't see anything, the local servers were completely broken.

I also didn’t know anything when I was calling /mcp. I just didn’t upload a screenshot — I had exactly the same issue.
I only sent it after it started working — I assumed that since there’s an error, it’s obvious it wasn’t working, so there was no point in uploading it.

I wrote that the second screenshot is after the initial run, when things are already working.

Best regards.