Remote Control silently inert on Windows: account device registration cleared to "none" with no notification, no log, and a healthy-looking auth status

What happened

On Windows, Remote Control silently stopped working across a whole working session. The root state turned out to be that the account's device registration had been cleared, but nothing anywhere said so — not in the desktop app, not in the CLI, not on the phone. The phone simply stopped listing sessions, and the Devices section went from showing the machine to showing only + Add device.

Diagnosing this took several hours because every layer reports success while the feature is inert.

Environment

• Windows 10 Pro 19045
• Claude Desktop app (MSIX), bundled Claude Code 2.1.246, updated to 2.1.247 mid-session
• CLI also installed natively: 2.1.251
• Pro subscription, single account, single org
• ~/.claude/settings.json contains remoteControlAtStartup: true

The observable state

%APPDATA%\Claude\ant-device-registry.json:

{
  "<ACCOUNT_ID>": "none:1788197898951",
  "keyless:<ACCOUNT_ID>": "kl1:<UUID>"
}

Both keys are the same account. The primary slot holds none:<timestamp> — the device is unregistered. A second keyless: slot still holds an id. I could not find any UI surface, log line, or command that reflects this state.

Why it is hard to notice

1. No notification when the binding is lost. The device disappears from the phone's Devices list with no message. Nothing is written to ~/.claude/debug — that directory had no files at all for the entire session.
2. claude auth status reports full health. It returns loggedIn: true, authMethod: claude.ai, subscriptionType: pro. Nothing indicates the device registration is gone.
3. Sessions still report as running. isRunning: true locally while the phone shows nothing, so the local side looks correct from every angle.
4. remoteControlAtStartup: true appears to do nothing in this state, and gives no reason why.

Secondary issues found along the way

These each cost significant time and seem worth separating:

• claude remote-control blocks silently on first run in a directory. It prints the spawn-mode prompt ([1] same-dir / [2] worktree) and waits. The process stays alive and looks healthy in the process list, but never registers a session. When several are launched at once from a script, there is no way to tell which ones are stuck other than looking at each window.
• claude remote-control refuses untrusted workspaces without offering the trust dialog. It exits with Workspace not trusted. Please run claude in <dir> first. Plain claude prompts and records trust; remote-control only errors. For anyone scripting server startup this is a dead end until they discover the manual step.
• Workspace trust is keyed to the exact path. Renaming a project directory (here C:\Agents\Claude code → C:\Agents\ClaudeCode) silently invalidates trust for every project underneath, with no hint that a previously trusted tree was renamed rather than newly created.
• An MSIX app update landed mid-session (2.1.246 → 2.1.247, staged at 20:10). This may or may not be related to the binding loss, but it correlates in time and resembles #86987.

Expected

• Losing the device binding should surface somewhere — a notification on the phone, a line in the CLI, or a non-healthy auth status.
• remote-control should either present the trust prompt or exit with a non-zero status that a script can detect.
• The spawn-mode prompt should not be reachable in a way that leaves a live-but-unregistered process.

Actual

Everything reports healthy; the feature does nothing; the only evidence is a JSON file in %APPDATA% that no documented command reads back.