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

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 ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗