/remote-control: desktop session works, mobile never receives anything — and no obvious way to report it from the app

Summary

Two related issues that compound each other:

1. /remote-control from a Claude Code CLI session never reaches the mobile Claude app. The desktop side keeps working normally (prompts go out, the assistant replies in the terminal), but the mobile client sees nothing — no incoming session, no notification, no error.
2. There is no discoverable way to report this from inside the mobile app itself. I went looking for a "Help", "Support", "Send feedback", or "Report a bug" entry point in the Claude mobile app and couldn't find one. If a feedback channel exists, it's hidden well enough that users won't reach it — which means problems with the mobile app probably go heavily underreported.

Filing this from desktop GitHub because that was the only working path.

Issue 1 — /remote-control silently fails to bridge to mobile

Expected

/remote-control either establishes a working bridge so the conversation continues on the mobile app, or surfaces a clear error explaining why it couldn't.

Actual

• CLI prints Remote Control connecting… exactly once.
• Local CLI session continues to work normally — I send prompts, the assistant responds.
• Mobile Claude app: nothing. No incoming session, no push notification, no error.
• No diagnostic on the desktop side either — there's no way to tell from the CLI whether the bridge ever came up.

Environment

• Claude Code (interactive CLI), Windows 11 Pro 10.0.26200
• PowerShell
• Model: Opus 4.7
• Same Anthropic account signed in on desktop and mobile.

Repro

1. Open an interactive Claude Code session on desktop.
2. Run /remote-control.
3. Send a prompt — observe local CLI reply normally.
4. Check mobile Claude app — nothing arrives.

Issue 2 — no findable way to report mobile bugs from the mobile app

While debugging Issue 1, I tried to file a bug from the phone (which is where the symptom is). I couldn't locate:

• A "Help" / "Support" / "Send feedback" / "Report a bug" menu entry.
• A "shake to report" gesture or any other obvious in-app feedback path.
• A link to documentation or status pages.

If such an option exists, it is buried deeply enough that an engaged user actively trying to file a bug couldn't find it. Practically speaking, that means most users hitting mobile-side problems will simply give up rather than reporting them — so your bug-intake from mobile is probably much sparser than the real rate of issues.

Suggestion: a clearly labelled "Report a problem" item in the settings/profile screen, ideally one that auto-bundles app version + device info + recent logs.

Combined impact

The two together create a silent failure mode: a desktop feature whose only failure surface is on the mobile app — and the mobile app has no reporting channel. Without filing from desktop, this would just be invisible to you.

Issue 3 — the app is running but cannot self-diagnose

Steping back: when the Claude mobile app is up and connected, it already knows whether a /remote-control session attempt arrived, whether a push subscription was registered, whether it dropped the event, whether the auth context matches the desktop side. It has all the state.

None of that is exposed. There is no "Diagnostics" screen, no "Show last 50 events", no "Why isn't this working" affordance. So a user with a working but mis-routing app has no path forward except guesswork ("is it VPN? account mismatch? push permission?") — which is exactly the wrong abstraction layer to debug from. Those questions are for the app to answer, not for the user.

If the app surfaced even a minimal event log ("last incoming session attempt: never" / "subscribed to channel X: yes/no" / "last server ping: 2s ago"), the user could file a useful report and your support team could act on it. Without that, mobile-only failures degenerate into "doesn't work, can't tell you more".

This is why Issues 1 and 2 compound so badly: a feature that fails only on mobile + a mobile app with no findable feedback channel + a mobile app that holds the diagnostic state but won't surface it = silent breakage by design.