Codex Desktop: Streamable HTTP MCP session wedges after a tool call loses its completion event

What issue are you seeing?

In Codex Desktop, a Streamable HTTP MCP server can enter a state where a tool call never produces an mcp_tool_call_end event. After that happens, later calls to the same MCP server also remain pending indefinitely, including read-only tools.

There is no timeout, cancellation, or error event in the Codex session log. The calls only have their originating custom_tool_call records and then remain suspended.

The MCP server itself remains healthy. During the failure I created a fresh, independent MCP session against the same endpoint:

• MCP initialize: HTTP 200 in 81 ms
• tools/call for a read-only statistics tool: HTTP 200 in 404 ms
• TCP and HTTP endpoint remained responsive

This rules out the server process, database write lock, and downstream vector service as the cause. The failure appears isolated to Codex's existing MCP session or tool-call bridge.

Observed timeline (UTC, redacted tool payloads):

• 17:45:29 — write tool completed normally; server duration about 3 ms
• 17:53:48 — read-only statistics tool completed normally in under 1 second
• 18:37:07 — write tool started; no mcp_tool_call_end
• 18:41:02 — another write tool started; no mcp_tool_call_end
• 19:00:25 — two read-only tools started; neither produced mcp_tool_call_end

The desktop log contains no MCP-specific timeout/cancel/error at those timestamps. It does show earlier request-layer instability during application startup: mcpServerStatus/list took 19.2 seconds, and app/list had Failed to send request / 60-second JSON parse failures.

What steps can reproduce the bug?

1. Configure a bearer-authenticated Streamable HTTP MCP server in config.toml, for example:

[mcp_servers.example]
url = http://127.0.0.1:18792/mcp
bearer_token_env_var = EXAMPLE_TOKEN
startup_timeout_sec = 20
default_tools_approval_mode = auto

1. Start Codex Desktop and invoke MCP tools from a task. Initial calls complete normally.
2. Keep using the task and MCP connection for an extended session.
3. Eventually one tool invocation remains pending indefinitely.
4. Cancel/terminate the pending tool execution from the task.
5. Invoke any other tool on the same MCP server, including a trivial read-only tool.
6. Observe that subsequent calls also remain pending with no completion, timeout, cancellation, or error event.
7. From a separate MCP client, initialize a new session against the same endpoint and invoke the same read-only tool. It completes immediately.

This is intermittent; I do not yet have a deterministic request count or duration threshold.

What is the expected behavior?

Every MCP call should either:

• complete successfully;
• fail with a surfaced transport/server error; or
• hit a bounded timeout and release the connection/request queue.

Cancelling a pending call should abort or detach that request cleanly so later calls to the same server can proceed. A lost response callback must not permanently wedge the MCP session.

Additional information

Environment:

• Codex Desktop: 26.707.3748.0
• Codex CLI/runtime: 0.144.0-alpha.4
• MCP protocol negotiated by a fresh session: 2025-03-26
• MCP server: Streamable HTTP, bearer authentication, localhost
• OS: Windows 10 Pro for Workstations 22H2, build 19045.6466, AMD64

Session logs confirm that earlier successful calls contain mcp_tool_call_end, while the affected calls have no matching end event. Full session logs are not attached because they contain private conversation data, but I can provide a minimized/redacted event extract if useful.