MCPs are defined in config.toml. Codex CLI sees them but VS Code IDE extension does not see them

+1 on this issue.

Frustratingly, the MCP server tools can be called fine in the Github Copilot Chat window (which i dont pay for unlike codex...), but the Codex VSCode extensions rarely picks them up.

I say rarely because, once in a blue moon, they do manage to start working, for brief windows of time. The Output window of the MCP servers offers no insight and the AI's own attempt at logging the situation provided no insight.

I tried a few things:

• initially was working in Ubuntu WSL (from windows store) and Codex was also sandboxed. 'Transport Closed' errors were common in this situation. It also had flashes in the plan where itd work.
• Trying to fix it,I moved the entire project off WSL and also removed all codex sandboxing and went pure windows on the local machine on windows OS. Same thing. Rarely working.

Would love to help try debug the issue if someone can guide me on how to try solve this one, given ive seen many reports with no solution for to this for a while now.

How are you checking whether the extension has them or not?

How are you checking whether the extension has them or not?

Thanks for the response.

I am checking whether the extension is able to use the MCP or not, simply by asking it. That is normal behavior for how we are expected to interact with MCPs, no?

When im using github copilot and it works there, i am simply talking to the model, and it makes the tool call on my behalf. It should, in an ideal world, be the exact same with the codex extension. However, the extension fails to establish communication with the server, even though the Extension with agent full access can easily query your PIDs and see the servers running, and tries to restart it, hit it constantly.

While troubleshooting again, after initiating the server via the VScode gui (with the MCP.json within the project workspace) i asked Codex to initiate the server itself. usually it fails, but somehow the process has managed to bind to the extension. Given i dont have any logging setup, i asked codex to explain. here is what it provided. i hope this helps. while this is the case for all MCPs including those from the VScode store, i also have my own server for a project, and thats what the below output pertains too.

I'd like to note that Codex will regulary try to initiate its own server and it does not always bind either. It got lucky this time i suppose.
***

Summary

Codex CLI can’t bind to an MCP stdio server started via VS Code’s MCP panel. The CLI only works after launching its own copy, so two independent instances can run with no warning.

Steps to Reproduce

1. Add a stdio MCP server in .vscode/mcp.json:

``json
"local-projectzero": {
"type": "stdio",
"command": "npm",
"args": ["--prefix", "F:/Code/ProjectZero/mcp", "start"]
}
``

1. In VS Code, start the server from the MCP panel (green triangle shows running; tools listed).
2. In a separate terminal, run Codex CLI and try to use local-projectzero without starting a new server from the CLI.

Expected

Codex CLI attaches to the already-running VS Code–managed stdio MCP server, or at least warns that it can’t and is starting its own.

Actual

Codex CLI can’t talk to the VS Code–started server. It only works after spawning a new npm --prefix F:/Code/ProjectZero/mcp start, resulting in two separate server processes.

Impact

• VS Code shows “Start | … tools” implying a shared server, but Codex can’t reuse it.
• Duplicate servers can run concurrently with no notice.
• Different configs (.vscode/mcp.json vs ~/.codex/config.toml); no shared runtime state.

Environment

• VS Code MCP panel (stdio)
• Codex CLI, PowerShell, Windows
• MCP command: npm --prefix F:/Code/ProjectZero/mcp start

Workarounds

• Start the MCP server from the host you plan to use (VS Code or Codex), or
• Request attach support or clearer warnings when a server is already running elsewhere.

There are a coupl eo fthings going on here:

1. Codex does jnot read VS Code's MCP configuration, that is just for copilot. Codex only uses config.toml
2. Although undesirable, Codex will often say it doesn't have access to MCP servers if you ask directly. This is undesirable model behavior but you'll usually have better luck with What mcp prefixed tools do you have access to?
3. We're about to launch a proper MCP UI in codex settings in the extension where it will be much more clear what is and isn't running as well as the ability to add new ones.

in that case:

• my config.toml, ive swapped it between node and npm here and there. if it does ignore that MCP file completely, then that is even more curious to me, as i have tried many times to spawn the server in a terminal with the same result.
• I agree you do have to be very specific with Codex. However, it is smart enough; that is you tell it to atleast list the tools, it will try query the server. Once it fails to get a response eg. Transport Closed when it was in WSL, windows fails during initialize (“connection closed: initialize response”), it will start trying to spawn its own or restart any it can find by PID. Codex is capable of establishing if the server even exists purely by the handshake before it even worries about tool calls. You can see this if you watch the models 'working/thinking' process in real time.

I look forward to the proper MCP UI. Hopefully these issues will be a bit easier to navigate if not resolve. Right now, it is actually hard to even reproduce.

I will continue my own debugging as the issue appears and if i find anything useful, i will post it here.

I just restarted VSCode (developer reload window, full system restart) and now have the same errors even launching the server via the shell so. It might not be a ubiquituous issues, but what i know is for those of us who have been reporting it, we dont know what were are going to get everytime we reload the server or vscode :(

I see that the issue is sorted. I can see the IDE extension for VS code is now reading config.toml to discover the toolsets, tool. Not sure if a fix was applied? @gpeal

<img width="1054" height="790" alt="Image" src="https://github.com/user-attachments/assets/daa0df10-0355-48c5-ad50-5061546e7648" />

P.S - appreciate the awseome work that the team is putting in.

I am not sure how to debug this locally. The IDE does not see the MCP servers again Codex CLI is at : OpenAI Codex (v0.73.0) and IDE Extension is at 0.4.51.

<img width="1058" height="800" alt="Image" src="https://github.com/user-attachments/assets/494dc180-0ef0-4f1b-b009-8f8db3880bc2" />

same issue

Coming back on this one, with some good news.

I have had some consistency when removing all sandboxing from the extension, running vscode natively on windows (not spawned via wsl), and specifically, launching the MCP server via the terminal within vscode, rather than a background/independant spawn.

still problems with either codex sanboxing options, ensuring to update config.toml when required.

id also like to note i tried wsl from within the terminal app shell, and the ubuntu wsl app from the windows store and both had the same issues

Hope this helps everyone!

This bug report hasn't received any upvotes or additional posts in three months. Closing.