[BUG] Remote Control: replies never arrive live (stuck loading), only appear after manual page reload

Status Open
Reported on v2.1.239
Maintainer reply None cached
Activity 0 comments · opened Aug 22, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Description

Remote Control sessions accept and display sent messages, but the assistant's reply never appears in real time — the
UI stays stuck in a "loading" state indefinitely on both the desktop app and browser. Manually reloading the page does
show the completed reply, confirming the local Claude Code CLI processed and answered the message correctly. Only the
live push/update to the web client is failing.

This started right after installing this morning's Claude desktop app update.

Environment

  • Claude Code version: v2.1.239 (confirmed current via claude doctor / npm update)
  • OS: Windows 11 Pro (10.0.26200)
  • Client: Claude desktop app (Windows), also reproduced in Chrome browser (claude.ai/code)

Steps to reproduce

  1. Start a Remote Control session locally: claude --remote-control
  2. Open the session URL in either the Claude desktop app or a browser
  3. Send a message
  4. Message appears as sent, but the reply area stays loading and never updates
  5. Reloading the page shows the completed reply was already generated and stored correctly

Troubleshooting already performed (all reproduce the same issue)

  • New Remote Control session (not stale) — same result
  • Desktop app AND Chrome browser — same result
  • Chrome Incognito, extensions disabled — same result
  • Windows Defender Firewall fully disabled — same result
  • Home network AND phone tethering (bypassing router/ISP) — same result
  • No VPN, no proxy, no custom DNS, no relevant hosts entries
  • claude doctor clean; sign-out/in and PC reboot done
  • Phone on cellular data (same session) DOES receive live replies — confirms local CLI↔relay connection is healthy;

issue is specific to this PC's client not receiving live pushes

What Should Happen?

● After sending a message in a Remote Control session (desktop app or browser), the assistant's reply should appear live
via the real-time channel, without needing to manually reload the page.

Error Messages/Logs

No explicit error messages appear in the UI (no toast/banner), except that the same
  Remote Control session this bug report is being drafted in itself disconnected mid-session
  with the following banner:

  "Remote Control disconnected. Claude Code on the computer that runs this session is no
  longer connected. Turn Remote Control back on there and this session will reconnect."

  Running `/remote-control` again in the local terminal reports the session as active again,
  but the client (browser/app) does not reliably resume receiving live updates afterward —
  consistent with the "stuck loading" symptom described above.

  Local CLI logs (`claude doctor`) reported no issues.

Steps to Reproduce

Steps to Reproduce
*
Please provide clear, numbered steps that anyone can follow to reproduce the issue. Important: Include any necessary
code, file contents, or context needed to reproduce the bug. If the issue involves specific files or code, please
create a minimal example.

● 1. On the local machine, start (or already have running) a Claude Code session with Remote
Control enabled: claude --remote-control

  1. Confirm the terminal shows "/remote-control is active" with a valid session URL

(e.g. https://claude.ai/code/session_...)

  1. Open that session URL from a second client — either the Claude desktop app or a browser

tab (claude.ai/code) — on the same PC

  1. Send a chat message from that client
  2. Observe: the message is shown as sent, but the reply area stays in a "loading" state and

never updates, even after waiting several minutes

  1. Manually reload the page — the reply that was "stuck loading" now appears, fully

generated, confirming the local CLI already processed and answered it correctly; only the
live push notification to the client failed to arrive

Also observed: the same Remote Control session can spontaneously show a
"Remote Control disconnected" banner mid-conversation, requiring /remote-control to be
re-run locally to reconnect — after which the client still does not reliably resume
receiving live updates.

This reproduces consistently regardless of:

  • New vs. reused Remote Control session
  • Desktop app vs. Chrome browser (including Incognito with extensions disabled)
  • Home Wi-Fi network vs. phone tethering (bypassing home router/ISP)
  • Windows Defender Firewall enabled vs. temporarily disabled

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

● Not precisely known — the issue began immediately after installing this morning's Claude desktop app auto-update (2026-08-22). The Claude Code CLI itself has remained at v2.1.239 throughout (before and after running claude doctor's npm update), so the regression appears tied to the desktop app update specifically, not the CLI. Exact prior desktop app version number was not captured before the update was applied.

Claude Code Version

● 2.1.239 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

● - Windows 11 Pro, build 10.0.26200

  • Issue is fully reproducible and not intermittent — every message sent via the

Remote Control web client (desktop app or browser) hangs in "loading" state; only a
manual page reload retrieves the actual completed reply

  • A second client (phone on cellular data, same session) receives live replies normally,

isolating the issue to this PC's client-side connection rather than the account or the
local CLI's connection to the relay

  • Screenshot of the "stuck loading" state and the "Remote Control disconnected" banner

would be useful to attach here if you have one handy — happy to help capture one if not

View original on GitHub ↗