### What version of Codex is running? codex-cli 0.40.0 ### Which model were you using? gpt-5-codex ### What platform is your computer? Darwin 24.6.0 arm64 arm ### What steps can reproduce the bug? Use the following config in `~/.codex/config.toml` ```toml model = "gpt-5-codex" model_provider = "litellm" model_reasoning_effort = "low" sandbox_mode = "danger-full-access" # MCP Servers # =========== [mcp_servers.context7] command = "npx" args = ["-y", "@upstash/context7-mcp", "--api-key",

gpt-5-codex unable to use MCP servers

Resolved 💬 3 comments Opened Sep 24, 2025 by AdiRishi Closed Sep 24, 2025

What version of Codex is running?

codex-cli 0.40.0

Which model were you using?

gpt-5-codex

What platform is your computer?

Darwin 24.6.0 arm64 arm

What steps can reproduce the bug?

Use the following config in ~/.codex/config.toml

model = "gpt-5-codex"
model_provider = "litellm"
model_reasoning_effort = "low"
sandbox_mode = "danger-full-access"

# MCP Servers
# ===========

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp", "--api-key", "API_KEY"]

When using gpt-5-codex, the model fails to output anything and seems to silently fail.
We can test this by using a simple prompt - Can you use context7 to get me react docs

What is the expected behavior?

If we switch our config back to gpt-5, we can see that the older model is able to successfully use MCP servers.
See the video below.

https://github.com/user-attachments/assets/83f22c11-92eb-4135-ad72-3314dc388bcc

What do you see instead?

Instead of any actual output, the prompt fails silently, and outputs nothing. See the video below

https://github.com/user-attachments/assets/a1266284-790a-45f7-ba3a-1a2213c43ad1

Additional information

I opened the codex-tui.log file to see if there was anything there, but the only log I could see on a fresh session was

^[[2m2025-09-24T02:27:44.253080Z^[[0m ^[[32m INFO^[[0m aggregated 3 tools from 2 servers

Also this is not just an issue with context7 MCP server, I tried to use sequential-thinking but that didn't work either with gpt-5-codex, same silent output

View original on GitHub ↗

3 Comments

AdiRishi · 11 months ago

Apologies, I was totally mislead on this error.

The actual issue is likely a bug in LiteLLM, which I was using as a proxy

[model_providers.litellm]
name = "LiteLLM"
base_url = "LITELLM_URL (obfuscated)"
env_key = "LITELLM_API_KEY"
wire_api = "responses"

More specifically, there is a bug in LiteLLM that affects the gpt-5-codex model that fails tool calls. I know this because a prompt like "tell me a poem" works fine, but "explore this repository" fails.

I'm closing this issue, I'll raise this on LiteLLMs side.

PabloLION · 11 months ago

Codex CLI is kinda stupid, when I ask "what MCP can you access" it says none, right after it used the MCP tool.

ItsRealDennis · 11 months ago

💡 Fix for “Request Timed Out” on Windows (Codex MCP)

Windows MCP servers often fail to start because:

Default startup timeout is only 10 s

Missing SystemRoot env var triggers a Winsock bug

Direct Node calls can misbehave

Quick fix: add this to your codex.toml (or similar):

[mcp_servers.any_server]
command = "cmd"
args = ["/c", "npx", "-y", "your-mcp-package", "--api-key", "YOUR_API_KEY"]
env = { SystemRoot = "C:\\Windows" }
startup_timeout_ms = 20000 # 20s startup window

Example – Render MCP

[mcp_servers.render]
command = "cmd"
args = [
"/c",
"C:\\Users\\Name\\AppData\\Roaming\\npm\\mcp-remote.cmd",
"https://mcp.render.com/mcp",
"--header",
"Authorization: Bearer <token>"
]
env = { SystemRoot = "C:\\Windows" }
startup_timeout_sec = 30
tool_timeout_sec = 120

This pattern works for any MCP server—just swap in your own package/executable.