Remote Control: responses never render in browser until manual page refresh (iPad Safari/Chrome, macOS Safari)

Additional environment detail I should have included: the local claude process is running inside tmux (tmux session, TERM=screen), not in a bare terminal.

Flagging it because the symptom may fit a tmux interaction: if the browser view mirrors terminal state, incremental redraws may not propagate through tmux, while a page refresh forces a full re-capture of the pane — which would explain why the complete response appears only after a manual reload.

I have not yet tested running claude outside tmux. Will follow up with that result. If it turns out to be tmux-specific, the title/framing of this issue should be narrowed accordingly.

Follow-up: tmux is ruled out.

Re-tested with claude started directly in Terminal on the iMac — no tmux, no ssh, fully local — then enabled Remote Control and connected from the browser. Behaviour is identical: nothing from the response renders until a manual page refresh, at which point the full response appears.

So the earlier tmux note is not the cause; please disregard it. The original report stands as filed: this reproduces in a plain local session, on every response, across iPad Safari, iPad Chrome, and macOS Safari.

Device/OS details:

• iPad Air (M1), iPadOS 18.7.3 — Safari and Chrome, both reproduce
• iMac (M4), macOS Tahoe 26.5.1 — Safari, reproduces

Safari versions are whatever ships with those OS releases (on iPadOS it is not separately updatable). Note the two Safari builds are several major versions apart and both are affected, as is Chrome on iPadOS.

Also reproducible on Firefox ESR 140.13.0 (Debian Trixie), not just Safari/Chrome as the title suggests — so this isn't platform-specific.

Debugging done on my end:

• Tab was in the foreground when replies arrived (rules out background-tab throttling)
• Reproducible in Firefox Troubleshoot Mode (all extensions disabled)
• DevTools → Network → WS: the WebSocket connection stays open (101 Switching Protocols)
• New frames (incoming, server → client) do appear in the Messages/Response panel at the moment a reply is sent, containing the correct reply content
• DevTools → Console: no JS errors logged when a reply arrives
• Despite the WebSocket frame arriving correctly and completely, the UI does not re-render until the page is manually reloaded
• Chromium on the same machine: works correctly, no refresh needed

So the WebSocket connection and data delivery work fine; the bug is client-side, in how (or whether) the UI re-render is triggered after an incoming WS frame — and it seems browser-dependent rather than isolated to Safari/Chrome.

mouzaf’s trace is the useful fork here. If the complete assistant frame reaches the browser and a reload reconstructs the same message, I wouldn’t spend the next pass on reconnect/SSE. I’d carry one sequence number through four probes: WS callback → decoded event → session reducer → store subscriber. The first missing sequence tells you whether this is routing/decode, an in-place mutation that preserves snapshot identity, or a subscriber that never fires.

The regression test I’d want mounts an existing session, feeds a real assistant frame through the production WS callback, and asserts the reply appears without navigation; then repeats after switching away and back. A reducer-only test can stay green while the React subscription bridge is broken.

I maintain BitFun, and we give each connection’s event streams explicit cursors at the app-server boundary: https://github.com/GCWing/BitFun/blob/main/src/crates/interfaces/app-server/src/server.rs#L20-L80. That split has been handy precisely because a healthy socket is not proof of a current view.