claude-code - 💡(How to fix) Fix [BUG] Desktop app: /remote-control mints link + connects bridge (main.log) but in-chat link/QR panel never renders

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

In the Claude Desktop app, typing /remote-control in the chat produces no visible output — no link, no QR code, no panel. However, the app's main.log shows the backend successfully enabling remote control and minting a https://claude.ai/code/session_… link on every invocation, with the bridge reaching connected. So the feature works end-to-end; only the in-chat link/QR panel fails to render. The connected session is reachable by manually opening claude.ai/code on mobile.

This worked normally ~2 days prior (the in-chat link appeared as expected), then silently stopped.

Root Cause

In the Claude Desktop app, typing /remote-control in the chat produces no visible output — no link, no QR code, no panel. However, the app's main.log shows the backend successfully enabling remote control and minting a https://claude.ai/code/session_… link on every invocation, with the bridge reaching connected. So the feature works end-to-end; only the in-chat link/QR panel fails to render. The connected session is reachable by manually opening claude.ai/code on mobile.

This worked normally ~2 days prior (the in-chat link appeared as expected), then silently stopped.

Fix Action

Workaround

Open claude.ai/code on the phone (same account) — the connected session is listed and tappable, no in-chat link needed.

Code Example

[info] Enabling remote control for session <local-session-id>
[info] [remote-control] bridge_state: ready
[info] Remote control enabled: https://claude.ai/code/session_<redacted>
[info] [remote-control] bridge_state: connected
[info] Mapping internal session <redacted> to CLI session <redacted>
RAW_BUFFERClick to expand / collapse

Summary

In the Claude Desktop app, typing /remote-control in the chat produces no visible output — no link, no QR code, no panel. However, the app's main.log shows the backend successfully enabling remote control and minting a https://claude.ai/code/session_… link on every invocation, with the bridge reaching connected. So the feature works end-to-end; only the in-chat link/QR panel fails to render. The connected session is reachable by manually opening claude.ai/code on mobile.

This worked normally ~2 days prior (the in-chat link appeared as expected), then silently stopped.

Environment

  • Claude Desktop app build 1.9255.2.0 (Windows, MSIX/WindowsApps install)
  • Bundled CCD / CLI runtime: 2.1.149 (per [CCD] Wrote SDK version file: 2.1.149 in main.log)
  • Auth: Max / claude.ai subscription via OAuth (cached token valid)
  • OS: Windows 11

Expected

Typing /remote-control shows the connect panel in chat (link + QR), as it did in the prior build.

Actual

/remote-control shows nothing in the chat. From the user's perspective it's a silent no-op. But main.log proves the backend ran successfully each time:

[info] Enabling remote control for session <local-session-id>
[info] [remote-control] bridge_state: ready
[info] Remote control enabled: https://claude.ai/code/session_<redacted>
[info] [remote-control] bridge_state: connected
[info] Mapping internal session <redacted> to CLI session <redacted>

Three separate invocations across the day each produced a fresh session_… link and bridge_state: connected. bridge-state.json shows enabled: true, userConsented: true, an active remoteSessionId, and synced message UUIDs. The bridge is fully functional — only the chat-side rendering of the connect panel is missing.

Impact

User cannot obtain the connect link from the desktop UI. The session IS remotely accessible, but only discoverable by manually navigating to claude.ai/code on another device — there's no in-app affordance, so it presents as "remote control is broken."

Reproduction

  1. Claude Desktop app (build 1.9255.2.0, bundled runtime 2.1.149), signed in with a subscription/OAuth account.
  2. In a chat session, type /remote-control.
  3. Observe: nothing renders in chat.
  4. Check AppData/Roaming/Claude/logs/main.log: the Enabling remote controlRemote control enabled: https://claude.ai/code/session_…bridge_state: connected sequence is present and successful.

Possibly-related change in the same window

In ~/.claude.json, the experiment flag tengu_velvet_cascade was removed from cachedExperimentFeatures within the same window the in-chat panel stopped rendering (it was present in a backup from before, absent after). Flagging in case that experiment gates the in-chat /remote-control panel UI specifically while leaving the bridge intact — may or may not be the cause; sharing the correlation since the timing lines up with the bundled-runtime bump to 2.1.149.

Workaround

Open claude.ai/code on the phone (same account) — the connected session is listed and tappable, no in-chat link needed.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING