Codex desktop app cannot reliably connect to local Streamable HTTP MCP servers on macOS

Open 💬 4 comments Opened Mar 8, 2026 by niejiaqiang

Summary

Codex desktop app cannot connect to a local Streamable HTTP MCP server on macOS in my environment.

  • stdio MCP servers work
  • the same local HTTP MCP servers work with direct local requests
  • but Codex reports a handshake / decode failure and appears unable to use the local HTTP server reliably

I tested both:

  1. a real Godot MCP server
  2. a minimal standalone MCP server using the official @modelcontextprotocol/sdk Streamable HTTP transport

Both servers worked when tested locally outside Codex, but Codex still failed to use them.

Environment

  • Codex desktop app on macOS
  • local MCP server URL: http://localhost:8765/mcp
  • also tested with a minimal server at http://localhost:8766/mcp

What I tested

A. Real local server

I built a local Godot MCP server using official MCP Streamable HTTP transport and exposed it on:

  • http://localhost:8765/mcp

The server:

  • accepted initialize
  • returned a valid mcp-session-id
  • handled notifications/initialized
  • returned valid JSON for resources/list
  • returned valid JSON for resources/read

B. Minimal standalone server

To rule out my app-specific code, I created a minimal MCP HTTP server using the official SDK only:

  • one ping tool
  • one fixed test://status resource
  • no Godot integration

This minimal server also worked correctly with direct local requests.

Reproduction

  1. Start a local Streamable HTTP MCP server on macOS, for example:
  • http://localhost:8766/mcp
  1. Add it to Codex as a Streamable HTTP MCP server
  2. Restart Codex
  3. Try to list resources or use the server

Expected behavior

Codex should connect and successfully list resources / call tools from the local HTTP MCP server.

Actual behavior

Codex fails to use the server and reports errors such as:

  • handshaking with MCP server failed
  • Unexpected content type: None
  • later, in some cases, error decoding response body

Important finding

The same server works outside Codex.

I verified locally that:

  • initialize succeeds
  • resources/list succeeds
  • resources/read succeeds
  • responses are valid application/json
  • session IDs are returned correctly

I also observed that when Codex attempts to connect, behavior does not match the successful direct local requests, and in some cases the local server does not receive the expected request sequence at all.

This suggests the issue is likely in Codex's local Streamable HTTP MCP client path, not in the tested local servers.

Minimal validation details

For the minimal test server:

  • direct local POST initialize returned 200
  • direct local POST resources/list returned valid JSON
  • direct local POST resources/read returned valid JSON

For the real server:

  • same result with valid initialization and resource responses

Question

Is there any known limitation or bug in Codex desktop app for local Streamable HTTP MCP servers on macOS, especially with localhost / loopback connections?

View original on GitHub ↗

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