Custom MCP connector: web client drops the stream mid-turn ("Connection interrupted"), works fine on mobile — same server, same connector

ChatGPT Apps SDK
1

Symptom

Mid-conversation, using a custom MCP connector, the assistant turn stops and the UI shows:

Connection interrupted. Waiting for the complete answer

The turn never completes on screen, but refreshing the browser reveals the finished answer — the turn completed server-side, only the browser’s stream was lost.

Web only — the key data point

Same connector, same server, same account, same tools. Running the identical flow on the ChatGPT mobile app: never stalls. A plain chat with no connector attached: never stalls. This isolates it to how the ChatGPT web client handles the connection during a turn with a custom MCP connector attached — not the connector, not the account, not the network.

What we ruled out on our side

  • Server erroring or slow — no. Every request returns 200 in under a second (Cloudflare wrangler tail), confirmed across multiple reproductions.
  • A specific tool/code path — no. The stall point moves between runs (sometimes right after the first tool call, sometimes several calls later).
  • Browser extensions — no, reproduces in Incognito.
  • Network/ISP — no, reproduces for end users elsewhere too.

Client details at initialize

client          = openai-mcp/1.0.0

protocolVersion = 2025-11-25

capabilities = {"experimental":{"openai/visibility":{"enabled":true}},

"extensions":{"io.modelcontextprotocol/ui":

{"mimeTypes":["text/html;profile=mcp-app"]}}}

We also see server/discover called before every single tools/call — the server never gets a session established, it’s re-discovered at every step. Our server runs stateless (sessionIdGenerator: undefined), which is what the official MCP Apps quickstart itself uses, so we don’t think that’s a misconfiguration on our end — but if stateless is no longer fully supported by this client we’d like to know.

Separately: window.openai.sendFollowUpMessage began returning a promise that never resolves or rejects on this client. Switching that call to the standard ui/message bridge measurably changed behavior (calls that never used to fire started firing) but did not eliminate the stall.

Related open threads, none resolved, all web-only MCP connector issues from the same window:

Impact

This is a live production tool. Every affected session needs a manual browser refresh mid-conversation to see an answer that already completed. Currently telling our users to use the mobile/desktop app instead of web.

Happy to provide exact UTC timestamps, a HAR file, Worker request logs, or a live reproduction on request.

2

Welcome to the forum!

You are welcome to discuss Codex issues on the forum, however the official place to report and track them is the GitHub issue tracker for OpenAI Codex.

I had ChatGPT look for the closest related issue and it could not find one that I would agree was a match. Here are the closest match which is closed and closest open issue match.

If any issue matches your problem, consider adding a :+1: reaction on the GitHub issue page itself, not just on the forum topic, as reactions on GitHub help the developers gauge impact and prioritize work.

If it is not the same issue, try searching the existing GitHub issues for a closer match. If you cannot find one, then open a new issue with as much detail as possible.

3

Thanks — to clarify, this isn’t a Codex issue. Codex isn’t involved anywhere in this report. This is a ChatGPT Apps SDK / custom MCP connector issue occurring in the ChatGPT web client. The only reason Codex appeared was that I cited a separate community thread whose author happened to compare their connector’s behavior across clients.

To restate the scope: a custom MCP server (Cloudflare Worker) connected to ChatGPT as an app. The ChatGPT web client drops the response stream mid-turn; the identical flow on the ChatGPT mobile app never does. Server returns 200 in under a second on every call.

4

You are absolutely correct. I was going to delete my reply but decided that it might be of help, I am wrong. Thanks.

5

We are having the exact issue.

6

All good and thank you for sharing and helping.

7

We are experiencing the exact same issue. In the middle of the chat response, ChatGPT suddenly displays “Connection Interrupted.” After a few seconds, if we refresh the page, the response appears, but the widget is missing.

8

Facing the similar issue

Confirming the same issue, with two additional data points: it hits the 2nd turn at very high frequency for us, and it also reproduces with a first-party app .

Setup

  • Custom MCP app: FastMCP (Python) behind Streamable HTTP, stateless (no Mcp-Session-Id minted), multi-replica on Kubernetes
  • Client observed at our server: User-Agent: openai-mcp/1.0.0, session terminated per request (Terminating session: None), re-discovery before tool calls — matching the fingerprint in the OP
  • ChatGPT web client, reproduces in a clean browser profile

Symptom (turn-2 pattern)

Turn 1 of an app conversation consistently succeeds — tools execute, widget renders. Turn 2 fails with “Connection interrupted. Waiting for the complete answer” at very high frequency — far too often to be network noise. Refreshing the browser sometimes reveals the completed answer, consistent with the OP’s finding that the turn completes server-side.

Server-side evidence (UTC, 2026-07-30)

Our logs for a failed turn show the full pipeline executing successfully while the web UI reported the interruption:

17:54:23  POST /mcp → 200
17:54:32  tools/call get_region → upstream API 200 (667 ms) → complete, req 
          a9a0e784-f0dc-493e-a9bf-f59817f943c0
17:54:38  tools/call detect_font_regions → 200 (634 ms) → complete, req 
          88cabc14-8ecb-4809-913e-3bde0e6e9e4e
17:54:43  resources/read ui://widget/... → 172 KB widget bundle served → 200

Every request 200, nothing slow, no errors. The stream died client-side after all tool work had finished.

First-party repro — this is not limited to custom connectors

The identical failure occurs with the built-in Booking app: turn 1 (“hi”) answers normally, turn 2 (“can you help me get a rental car…”) hangs and shows the same “Connection interrupted” message. Screenshot available. Since first-party launch apps are affected, this can’t be a connector-implementation issue.

Impact

Blocks any multi-turn app flow on web (our app’s core UX is iterative — e.g., adjusting a crop region across turns). Currently directing users to refresh or use the desktop/mobile app.

Happy to provide full logs with request IDs, HAR files, exact UTC timestamps, or a live repro on request.

Also please assist us if something is required at our end

image (32)
image (32)1812×1190 100 KB

image (34)
image (34)2010×1888 162 KB

image (33)
image (33)1902×1906 277 KB