Remote Control no longer available — was previously working

[AgileSmagile]

Description

/remote-control is no longer available. It was previously working on this account and has stopped without any communication or changelog notice.

Steps to reproduce

1. Inside a Claude Code session, type /remote-control → returns "Unknown skill: remote-control" (command doesn't appear in the skill list at all)
2. From the terminal, run claude remote-control → returns:

Error: Remote Control is not yet enabled for your account.
Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76

Expected behaviour

Remote Control should work as it did previously. This account has been using Remote Control regularly — this is not a first-time setup issue.

Environment

• Claude Code version: 2.1.85
• Platform: Windows 11 Pro (10.0.26200)
• Shell: bash
• Plan: Individual (Pro) — same plan as when Remote Control was working
• Auth: claude.ai OAuth (not API key)

Additional context

• No changes were made to authentication, plan, or settings between the last successful use and this failure.
• The UV_HANDLE_CLOSING assertion failure in the error output suggests a possible Windows-specific regression in addition to the feature flag issue.

[linfisher]

Same regression here — Remote Control was working perfectly for days, then died immediately after updating Claude Code. Nothing local changed.

Environment: macOS (Darwin 25.5), Claude Code desktop app + CLI sessions, remote control previously verified working phone-to-desktop since 2026-08-01.

Timeline:

• Remote control in daily use, multiple long-running sessions, machine never slept, sessions never closed.
• Installed the Claude Code update on 2026-08-03. Remote control stopped at that moment.
• "Enable remote control by default" toggle in desktop Settings: still ON.
• Full app quit + relaunch: no effect. New sessions: do not register.

Diagnostic evidence:

• ~/.claude.json -> cachedGrowthBookFeatures.tengu_onyx_plover.remoteEnabled is now FALSE.
• Manually editing it to true restores nothing durable: the next app launch re-fetches the flag cache and rewrites it to false. So the disable is being served from the flag backend, overriding the user's own settings toggle with no UI indication and no changelog entry.

Expected: the Settings toggle governs remote control, or at minimum the UI says the feature is unavailable. Actual: toggle says ON, phone shows nothing, and the reason is only discoverable by reading the cached flag JSON. Happy to provide logs or version specifics if useful.