MCP servers registered but tools not injected into threads in Codex CLI >=0.120.0

Resolved 💬 3 comments Opened Apr 26, 2026 by deqiying Closed Apr 28, 2026

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

What version of Codex CLI is running?

0.122.0-alpha.13

What subscription do you have?

This looks like a regression in the Codex runtime/thread tool injection layer, not a server configuration issue.

Which model were you using?

gpt-5.4

What platform is your computer?

Darwin 25.4.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

zsh

What issue are you seeing?

After upgrading Codex CLI to codex-cli 0.122.0-alpha.13, configured MCP servers were still visible through codex mcp list / codex mcp get, but their tools were not exposed inside new Codex threads. The same MCP configuration works
again after downgrading to codex-cli 0.120.0.

This looks like a regression in the Codex runtime/thread tool injection layer, not a server configuration issue.

What steps can reproduce the bug?

Minimal reproduction

Configure an MCP server in ~/.codex/config.toml:

```toml
[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"

Verify registration:

codex mcp list
codex mcp get openaiDeveloperDocs

Start a new Codex thread on codex-cli 0.122.0-alpha.13.
Ask the agent to use the OpenAI Developer Docs MCP, for example:

Use the openaiDeveloperDocs MCP tool to search for Codex MCP configuration docs.

Observe that no mcp__openaiDeveloperDocs__search_openai_docs or equivalent MCP tool call is available/executed in

the thread, despite the server being enabled.

Downgrade to codex-cli 0.120.0 with the same config.
Repeat the same prompt and observe that MCP tool calls are available and succeed.

What is the expected behavior?

# MCP servers are registered but MCP tools are not injected into Codex threads in 0.122.0-alpha.13

## Summary

This looks like a regression in the Codex runtime/thread tool injection layer, not a server configuration issue.

## Environment

OS: macOS
Shell: zsh
Last known working version: codex-cli 0.120.0
Affected versions: stable Codex CLI versions greater than 0.120.0 are also affected
Previously observed affected build: codex-cli 0.122.0-alpha.13
Auth mode: API key auth
Provider path: OpenAI-compatible Responses provider
MCP config location: ~/.codex/config.toml
MCP server used for minimal repro: openaiDeveloperDocs
MCP transport: streamable_http
MCP URL: https://developers.openai.com/mcp

## Expected behavior

When an MCP server is enabled in ~/.codex/config.toml, and codex mcp list / codex mcp get show it as enabled,
Codex threads should expose the server's callable tools to the agent, for example:

mcp__openaiDeveloperDocs__search_openai_docs
mcp__openaiDeveloperDocs__fetch_openai_doc

A user prompt such as "Use the OpenAI Developer Docs MCP tool to search Codex MCP docs" should result in a real MCP
tool call.

## Actual behavior on 0.122.0-alpha.13

The MCP server was registered and enabled, but new Codex threads did not receive callable MCP tools.

Observed behavior:

codex mcp list showed openaiDeveloperDocs as enabled.
codex mcp get openaiDeveloperDocs showed:
enabled: true
transport: streamable_http
url: https://developers.openai.com/mcp
New threads still had no visible/injected mcp__openaiDeveloperDocs__... tools.
No successful thread-level call to search_openai_docs or fetch_openai_doc could be demonstrated.
The failure was classified as partial because registration worked, but real thread tool usage did not.

## Behavior after downgrade to 0.120.0

After downgrading to codex-cli 0.120.0, the same environment can use MCP tools from the thread.

Verified current behavior:

codex --version reports codex-cli 0.120.0.
codex mcp list shows multiple enabled MCP servers, including openaiDeveloperDocs.
A real thread-level call to mcp__openaiDeveloperDocs__search_openai_docs succeeds and returns OpenAI docs search

results.

A real thread-level call to mcp__openaiDeveloperDocs__fetch_openai_doc succeeds for `https://developers.openai.com/

codex/mcp`.

This confirms the MCP server itself is usable and the config is not fundamentally broken.

## Minimal reproduction

Configure an MCP server in ~/.codex/config.toml:

```toml
[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"

Verify registration:

codex mcp list
codex mcp get openaiDeveloperDocs

Start a new Codex thread on codex-cli 0.122.0-alpha.13.
Ask the agent to use the OpenAI Developer Docs MCP, for example:

Use the openaiDeveloperDocs MCP tool to search for Codex MCP configuration docs.

Observe that no mcp__openaiDeveloperDocs__search_openai_docs or equivalent MCP tool call is available/executed in

the thread, despite the server being enabled.

Downgrade to codex-cli 0.120.0 with the same config.
Repeat the same prompt and observe that MCP tool calls are available and succeed.

## Important note about resources/list

During debugging, resources/list and resources/templates/list returned:

Mcp error: -32601: Method not found

This should not be treated as the root problem. The openaiDeveloperDocs MCP server is tool-oriented and exposes tools
such as:

search_openai_docs
list_openai_docs
fetch_openai_doc
list_api_endpoints
get_openapi_spec

The regression is that Codex 0.122.0-alpha.13 did not inject the MCP tools into the thread, not that the server lacks
resources.

## Suspected regression area

The likely failing layer is one of:

MCP tool discovery during thread startup
dynamic tool injection into the agent thread
app-server / runtime bridge between configured MCP servers and model-visible tools
compatibility between API-key auth / OpenAI-compatible provider path and MCP tool injection

## Why this looks like a Codex bug

The same MCP server and config satisfy all lower-level checks:

Server is registered.
Server is enabled.
Transport and URL are valid.
Direct tool-oriented MCP usage is valid.
Downgrading Codex makes thread-level MCP tool calls work again.

The failure only appears in the newer Codex runtime where enabled MCP servers do not become callable tools inside the
thread.

## Requested fix

Please check whether 0.122.0-alpha.13 introduced a regression that prevents configured MCP servers from being surfaced
as thread tools, especially for streamable HTTP MCP servers and API-key/OpenAI-compatible provider setups.

It would also help if Codex exposed a diagnostic command that distinguishes:

MCP server configured
MCP server initialized
MCP tools discovered
MCP tools injected into the current thread
MCP tool call executed successfully

Additional information

This is not limited to an alpha build. The issue was previously observed on codex-cli 0.122.0-alpha.13, and stable
Codex CLI versions greater than 0.120.0 also show the same behavior.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

#19425
#19363
#18527
#19304

Powered by Codex Action

etraut-openai contributor · 4 months ago

Thanks for the detailed report. I’m not yet convinced this is a general MCP injection regression.

A couple of details make the current evidence ambiguous:

codex mcp list / codex mcp get confirm the server is configured and enabled, but they do not prove that a new thread initialized the server successfully or that tools/list returned usable tools for that session.
In newer builds, MCP tools may be exposed as Responses namespace tools rather than as separate top-level flattened tool names. For this server, I’d expect to look for a namespace like mcp__openaiDeveloperDocs__ with child tools such as search_openai_docs, not only a top-level mcp__openaiDeveloperDocs__search_openai_docs.
If tool_search is enabled, some tools may also be discoverable through tool_search rather than always appearing directly in the initial tool list.

Could you share the raw tools array from the failing Responses request on 0.122.x+? The useful things to check are:

Is there a type: "namespace" tool for mcp__openaiDeveloperDocs__?
Is tool_search present?
Are there MCP startup/status logs showing whether tools/list succeeded or failed for openaiDeveloperDocs?
Does the same setup fail with the native OpenAI provider, or only with the OpenAI-compatible/custom provider path?

If the custom provider/proxy is dropping or rejecting namespace tools or client-executed tool_search, that would explain the observed downgrade difference, but it would be a narrower custom-provider compatibility issue rather than MCP configuration generally not being injected.

deqiying · 4 months ago

Thanks for looking into this.

I have confirmed that this was not a Codex CLI bug. The MCP servers were registered correctly, but my custom AI gateway/proxy was not fully compatible with the latest Codex /v1/responses protocol used by Codex CLI >= 0.120.0.

Because the gateway did not correctly handle/forward the newer Responses API payload, the MCP tool definitions were not being injected into the actual model requests/threads. After fixing the gateway compatibility with /v1/responses, the MCP tools are injected correctly.

So the root cause was on my side, not in this project. I’m closing this issue as resolved.

Thanks again for your time.