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

UPDATE: This is not a single stale session. After registering a brand-new environment,
the 404 returned on the next launch with a DIFFERENT session ID (cse_<REDACTED_2> vs the
original cse_<REDACTED_1>), on the same fresh environment. Sessions appear to be created
and then not found at worker-attach time, seconds later. Abandoning the environment does
not fix it — the new environment reproduces the failure and leaves an undeletable duplicate
row in the picker.

Remote Control: a ghost session can permanently 404 an environment, and stale environments can't be removed or told apart

Preflight Checklist

• I have searched existing issues (this extends [FEATURE] Let users remove stale/dead Remote Control environments from the claude.ai/code environment list #50884 with a case where the missing delete affordance is not merely cosmetic)
• This is a single bug report
• I am using the latest version of Claude Code (2.1.208)

What's Wrong?

Two problems that compound each other: a stale session can permanently break an environment, and there is no way to remove the environment you're then forced to abandon.

1. A ghost session 404s on every launch

Every claude remote-control start printed:

Error: CCR v2 worker registration failed for session cse_<REDACTED>:
Request failed with status code 404

Same session ID each time, reproducible across restarts, on the latest build, with claude doctor clean and no ANTHROPIC_* variables set. The environment's server-side session list contained a session that no longer existed, so the bridge tried to attach a worker to it on every start and failed.

The session ID is not stored locally — grep -rl "cse_<id>" ~/.claude ~/.claude.json returned nothing. Only the environment pin is local:

~/.claude/projects/<mangled-project-path>/bridge-pointer.json

Workaround: move bridge-pointer.json aside, forcing registration of a fresh environment. This clears the 404 — but the only escape from a bad environment is to abandon it, which strands the old one in the picker forever. Which leads to:

2. Stale environments cannot be removed or told apart

The picker now shows two identical, dead rows:

Remote Control
  <Folder>   0 of 32   <Hostname>
  <Folder>   0 of 32   <Hostname>

• No delete affordance in the CLI, web, or mobile app.
• Confirmed server-side: the rows appear at claude.ai/code in a browser, not just in Desktop. Signing out and relaunching does not clear them. Nothing local references them.
• Environments cannot be renamed. The label is derived from folder name + hostname, so two environments registered from the same directory are visually indistinguishable. The only tell between live and dead is the capacity count.

Contributing factor: Claude Desktop Code sessions also register Remote Control environments (via Settings → Claude Code → Enable remote control by default). This made the source hard to trace — ps aux | grep "claude remote-control" returned nothing while the rows persisted, because the registering processes were Desktop Code sessions, not a remote-control server.

Steps to Reproduce

1. Run claude remote-control in a project directory. Note the environment ID.
2. Get the environment into a state where a session in its list no longer exists server-side. (In my case this happened on its own; I don't have a deterministic trigger.)
3. Observe the 404 on every subsequent launch. It survives restarts and claude update.
4. Move ~/.claude/projects/<project>/bridge-pointer.json aside and relaunch.
5. The 404 is gone, but the picker now permanently shows two identical rows for the same folder — one live, one dead — with no way to remove either.

Expected Behavior

• Orphaned sessions are reaped server-side, so a dead session ID cannot permanently 404 an otherwise healthy environment.
• The CLI can drop a bad session without abandoning the whole environment.
• Remote Control environments can be deleted from the web, mobile, and CLI.
• Environments can be named, or the picker surfaces the working directory, so two entries from the same folder are distinguishable.
• Sessions deregister gracefully on shutdown so rows don't strand.

Impact

The current best workaround is to ignore the environment picker entirely and navigate by environment URL. For anyone using Remote Control regularly, the picker fills with dead, identically-named entries and stops being usable.

Environment

• Claude Code: 2.1.208 (native install)
• Platform: macOS, darwin-arm64
• Shell: zsh
• Also installed: Claude Desktop (Code tab), remote control on by default//