[BUG] Desktop app: /remote-control mints link + connects bridge (main.log) but in-chat link/QR panel never renders

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 control → Remote 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.