Bug: /remote-control fails silently on an outdated / non-auto-updating build

Environment: Windows 11 · Claude Code desktop UI + CLI · claude.ai auth (paid tier) · no ANTHROPIC_API_KEY / Bedrock / Vertex / Foundry env vars set.

Problem

Typing /remote-control produced no output and no error — the command appeared to simply not work, with zero indication of why.

Root cause (found by process of elimination)

The Claude Code app build was outdated and not auto-updating. Notably, the CLI reported a current version (2.1.156) while the app actually being driven had diverged to an older build below the /remote-control minimum of v2.1.51 — so the version state looked fine on the surface. Uninstalling and reinstalling brought it current, after which /remote-control worked immediately.

Why it matters

Because the failure was completely silent, diagnosing it meant ruling out auth method, environment variables, subscription tier, and OS/UI surface before landing on "the install is just stale." Many users are likely unable to activate /remote-control purely due to an outdated or non-auto-updating install, with nothing pointing them at the version as the cause.

Requests

1. Don't fail silently. When /remote-control can't run, surface the reason inline — e.g. "Remote control requires Claude Code v2.1.51+ (you're on vX.Y.Z) — update to enable", or "requires claude.ai login", etc. Even a generic "this command isn't available in your current version/configuration" is far better than no output.
2. Fix / investigate desktop auto-update reliability — the app was not auto-updating. At minimum, show an "update available" nudge, especially when a gated command is attempted on an outdated build.
3. Surface CLI ↔ app version divergence in /doctor / /status (e.g. flag "a newer version is available").

_Aside: /bug was not available in this environment, which is why this is filed on GitHub._