[Bug] /remote-control silently no-ops on Pro plan (no output, no error) — cached flag shows remoteEnabled: false

What's Wrong?

/remote-control silently does nothing on a Pro plan — no output, no error message, no /rc active indicator. Repeated attempts across multiple sessions all produce the same silent no-op.

Environment:

• Claude Code version: 2.1.212 (npm-global, commit 8b2783a8f907)
• Platform: macOS (darwin-arm64), Darwin 25.2.0
• Plan: Pro (claude auth status → "subscriptionType": "pro", "authMethod": "claude.ai", "apiProvider": "firstParty")
• ANTHROPIC_API_KEY: not set
• ANTHROPIC_BASE_URL: not set
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC: not set
• claude doctor: "No installation issues found"

Evidence it's server-side gating:

The cached feature flags in ~/.claude.json show Remote Control disabled for this account:

"tengu_onyx_plover": { "enabled": false, "minHours": 24, "minSessions": 3, "remoteEnabled": false }

Notably, "hasUsedRemoteControl": true is also present in the same file, suggesting the feature worked on this account previously and was later gated off — consistent with reports in #29185 of access being granted then revoked during the rollout.

What Should Happen?

Per https://code.claude.com/docs/en/remote-control, Remote Control is available on Pro plans. Running /remote-control should enable the session for remote access (with /rc active shown in the footer), or at minimum print an actionable error such as "Remote Control is not yet available on your plan" instead of failing silently.

Steps to Reproduce

1. Log in with a Pro account via /login
2. Run /remote-control in an interactive session
3. Nothing happens — no output, no error, no footer indicator

Related Issues

• #29185 (closed as stale)
• #72603, #28817, #29449 (open, marked duplicate — same Pro-plan symptom, but with an explicit error message rather than a silent no-op)
• #72124 (previously working, then unavailable — matches the hasUsedRemoteControl: true observation here)

Additional Information

Requesting Remote Control access be enabled for this account (org: sathish4earn@gmail.com's Organization), as was reportedly done manually for other Pro users in #29185. Also suggesting the client print an explicit error when the feature flag disables the command, rather than exiting silently.