[Bug] Remote Control: stale environments cannot be deleted and ghost sessions cause permanent 404 errors

Confirming this on Claude Desktop 1.24012.9, macOS 26.6 (arm64), Max plan — still present, and with one new detail that I think matters for the "how do you tell live from dead" part.

The capacity counter is not live at all.

This issue and #78695 both note that the only tell between a live and a dead environment is the session count. That heuristic doesn't hold. In my case the picker shows:

Remote Control
  Claude   <host>   0 of 32
  Claude   <host>   2 of 32

I fully terminated Claude Desktop on the host machine and verified it was gone (pgrep -x Claude empty, no claude CLI installed on that machine at all). Both rows stayed, and the second one kept reading 2 of 32 — two sessions attributed to a host with no process running. So a stale environment can show a non-zero count, and a count of zero doesn't mean the environment is the dead one either. There is currently no reliable way to tell them apart.

Desktop-hosted equivalent of bridge-pointer.json

Your note that Desktop Code sessions register environments (and therefore ps aux | grep "claude remote-control" finds nothing) was exactly right, and cost me a while to work out independently. For the Desktop path the local pin lives at:

~/Library/Application Support/Claude/bridge-state.json

keyed by <orgId>:<accountUuid> — no device component, so there is a single environmentId per app installation and it is overwritten in place. Same failure shape as moving bridge-pointer.json aside: the previous environment is never deregistered, and once the id is overwritten nothing local references it, so the app can't release it on quit either. Grepping all Claude state on two machines for env_ returns only this one file, holding only the current id.

Also ruled out here, in case it saves anyone time

| Attempted | Result |
|---|---|
| Cmd+Q and relaunch | Both rows remain |
| Reboot the host machine | Both rows remain |
| Signing out of the account in Claude Desktop on the host | Both rows remain; bridge-state.json untouched, still enabled: true with the same environmentId |
| Settings → Claude Code → Enable remote control by default toggle | bridge-state.json byte-identical afterwards; the setting isn't persisted in the app's config.json either |
| Right-click the row in the picker | No context menu |
| claude.ai/code web picker | Same two rows; in the DOM they are bare menuitemradio elements — no delete control, no submenu, nothing revealed on hover |

One difference from #78695: environmentId stayed constant across several app restarts, so the Desktop path doesn't accumulate a new environment per launch. The orphan here appears to be a one-off leftover from an earlier reinstall or re-login, which I couldn't reproduce after the fact.

Happy to supply environment ids and account details privately.

Additional datapoint — a slightly different flavor of the same server-side dangling reference: in our case it is the worker itself that keeps retrying a ghost session at every startup.

Setup: claude remote-control running 24/7 under systemd (Ubuntu Server 26.04). At every service start over the past week and a half (9 starts, currently on CLI 2.1.223), the worker logs:

Error: CCR v2 worker registration failed for session cse_01Acw…: Request failed with status code 404

Always the same weeks-old session id. The environment itself re-registers fine and new sessions work, so this is harmless day-to-day — but the dangling reference survives CLI version updates, nothing in the CLI or the apps lists it, and so nothing can delete it.

Corroborates both halves of this issue: session records that go missing server-side while a client still holds a reference to them, and no cleanup path for the resulting ghost.

+1, hitting this too. Adding a clean repro in case it helps narrow the cause down — this one isn't from a directory-layout change, just plain restarts of the same server pointed at the same unchanged directory.

Setup: Windows 11, native claude.exe install, claude remote-control --spawn same-dir --capacity 4 launched by a Task Scheduler job (restarts the server on legitimate triggers — a local config fix, a network-outage self-heal check, etc. — so restarts happen periodically over the life of the setup, not just once).

Repro:

Start claude remote-control in a directory. Console prints an environment URL: https://claude.ai/code?environment=env_AAAAAAAA.
Stop the process, start it again in the exact same directory (no path change, no casing change, nothing).
Console prints a new ID: env_BBBBBBBB.
Repeat over a few days of normal restarts → mobile app (Devices → [device]) now lists the same local folder as N separate entries, one per historical restart, with no way to tell which is the live one.
Over three days of intermittent restarts I've got 4 entries for one folder now.

Ruled out on my end, in case it saves someone time:

Not a local .claude.json issue — that file only ever has one correct/trusted entry for the directory at any point in time.
Not an app-cache issue — reinstalling the mobile app wouldn't touch this, since the entries reflect live backend state, not something cached client-side.
No CLI escape hatch — claude remote-control --help has no list/revoke flag.
So it looks like every server start unconditionally mints a new environment registration rather than reusing/updating an existing one for the same directory — the duplicate-entries-on-layout-change case in the OP is one trigger, but a plain restart with nothing changed is enough on its own.

+1 on the OP's proposed fixes — either reuse-by-directory on restart, or a delete/revoke action (CLI or UI) so this doesn't grow unbounded on any setup where the server restarts periodically by design.