[BUG] Claude Code on the web (iPhone Safari): assistant replies never render until manual refresh, while the elapsed-time counter keeps updating

Summary

On iPhone Safari, an open Claude Code web session never renders the assistant's reply. The turn completes normally server-side, but the page keeps showing the working spinner indefinitely. A manual pull-to-refresh instantly shows the full reply. This happens on every turn.

The tell that makes this more than "mobile is slow": the elapsed-time counter keeps ticking up the whole time (2m 11s, 5m 16s, …). So the page is connected and receiving events — it renders the progress updates fine. It's specifically the assistant message that never appears.

Steps to reproduce

1. Start a session from the CLI and enable remote control.
2. On an iPhone, open the session at claude.ai/code/session_… in Safari (not the app).
3. Send a message and leave the page alone — don't switch tabs, don't refresh.
4. Wait for the turn to finish.

Expected: the reply renders as it streams, or at latest when the turn ends.
Actual: the spinner and the seconds counter run forever. Pull-to-refresh renders the complete reply immediately.

I left one turn for 5+ minutes after the session had already gone idle server-side. Nothing appeared until I refreshed.

What it isn't

The same session in desktop Chrome updates live, with no reload at all — I watched a full turn arrive with the page untouched.

It also isn't the mobile bundle or a responsive breakpoint:

• Forcing an iPhone user agent in desktop Chrome → still updates live.
• iPhone UA plus a 430×932 mobile viewport → still updates live.

So whatever is different appears to be the iOS runtime itself, not what the server decides to serve to a phone.

Possibly relevant protocol detail

Watching the same session in desktop DevTools, the page opens

wss://claude.ai/v1/sessions/ws/session_<redacted>/subscribe?organization_uuid=<redacted>

and immediately sends, ~1 ms after open:

{"request_id":"…","type":"control_request","request":{"subtype":"initialize"}}

The server answers with a ~32 KB state frame, after which the message-content frames (roughly 1–24 KB each) arrive and render as the reply streams. Alongside those, small ~240-byte token-progress frames arrive about every 1.4 s.

On iOS, the ~1.4 s progress cadence is clearly getting through — that's what drives the counter — while the message content never appears. That pattern would be consistent with the subscribe/initialize step not completing on iOS, leaving the client subscribed to progress broadcasts but not to session events. I can't verify the socket traffic on the phone directly, so treat the mechanism as a hypothesis; the symptom and the desktop comparison are solid.

Environment

• iPhone, iOS 26.x, Safari
• Claude Code on the web (claude.ai/code), remote-control session started from the CLI
• Reproducible on every turn, over many days
• Desktop (Chrome, macOS): unaffected

Related

• #53745 — same symptom, "each turn I have to refresh my browser to have a response populate" (platform:ios), closed as not planned with no maintainer reply
• #41670 — mobile Safari works where the iOS app fails, for sending
• #51267 — sessions hanging mid-execution (different failure, same area)