Codex MCP fetch fails to start: handshake "connection closed: initialize response"
After mcp-server-fetch updated to 2026.7.10, my Codex MCP client fails to start the fetch server with "MCP client for fetch failed to start: MCP startup failed: handshaking with MCP server failed: connection closed: initialize response" when launched via uvx. Is this a dependency resolution problem, and what configuration fixes it?
Originally asked on GitHub: https://github.com/modelcontextprotocol/servers/issues/4600
5 answers
Fixed in
mcp-server-fetch2026.8.18. A maintainer confirmed the package now declaresmcp>=1.29.0,<2, so a plainuvx mcp-server-fetchresolves a working 1.x SDK again and the--with mcp<2workaround is no longer needed.Root cause: version 2026.7.10 declared
mcp>=1.1.3, souvxresolved mcp 2.0.0, whereMcpErrorwas renamed toMCPError. The failure is anImportErrorat module import, before any transport opens, which surfaces asconnection closed: initialize response. Python 3.13 fails identically to 3.14, so the interpreter version is not responsible. The maintainer also said the failure does not appear to be related to the 2026-07-28 stateless protocol revision.Workarounds that worked in the thread before the fix:
- Pin the SDK range in Codex's config.toml:
args = ["--with", "mcp<2", "mcp-server-fetch"]— verified by the reporter with a real MCP handshake (mcp-fetch 1.29.0, tools=fetch). Apply it, then restart Codex; the Inspector's "Web is up" message only confirms the Inspector UI started, not that the fetch server connected. - Run the Docker image:
command = "docker",args = ["run", "-i", "--rm", "mcp/fetch"]— worked for one commenter locally.
A commenter confirmed the last 1.x SDK release,
--with mcp==1.29.0 mcp-server-fetch, as a valid fix, but no one in the thread reported running it. Two other uvx pins (mcp==1.12.1, with and without an explicitmcp-server-fetch==2026.7.10) were suggested by a coding agent but explicitly not tested.Security note: the SDK floor was raised to 1.29.0 because the older range also resolved versions affected by GHSA-vj7q-gjh5-988w, GHSA-jpw9-pfvf-9f58, and GHSA-hvrp-rf83-w775; a commenter also noted a compatibility fix is not automatically a security result for servers exposed beyond your own machine.
Did this work for you?- Pin the SDK range in Codex's config.toml:
What a GitHub user tried on GitHub (Worked)
Reporter pinned the SDK range with
uvx --with mcp<2 mcp-server-fetchin Codex's config.toml and verified a real MCP handshake (mcp-fetch 1.29.0, tools=fetch).Source: https://github.com/modelcontextprotocol/servers/issues/4600 (opens external site)
Did this work for you?What @slouffka tried on GitHub (Worked)
Commenter switched to the Docker fetch server (
command: docker,args: ["run", "-i", "--rm", "mcp/fetch"]), which started successfully while the uvx setup was broken.Did this work for you?What @mpapadopoullos tried on GitHub (Outcome unclear)
Commenter confirmed the last 1.x SDK release,
--with mcp==1.29.0 mcp-server-fetch, as a valid fix, but no one in the thread reported running it.Did this work for you?What @slouffka tried on GitHub (Outcome unclear)
A coding agent suggested
--with mcp==1.12.1(with and without an explicitmcp-server-fetch==2026.7.10pin); the commenter explicitly did not test them.Did this work for you?
Related questions
- mcp-server-fetch: 'AnyUrl' object has no attribute 'decode' error
- Does the official MCP Postgres example validate SQL before executing it?
- How to fix UTF-8 Japanese text corruption/crash in mcp-server-sqlite with Claude Desktop on Windows?
- MCP Knowledge Graph Memory Server fails with ${workspaceFolder} in MEMORY_FILE_PATH
- npx @modelcontextprotocol/server-filesystem: ERR_MODULE_NOT_FOUND for zod-to-json-schema