Ghost remote sessions persist in "Remote Control" panel with no way to dismiss them

[yoshovski]

Summary

Two dead sessions remain listed in the desktop app's Remote Control panel indefinitely. They cannot be dismissed: hovering a row only offers "End session" for active sessions, and these ghosts have no active session behind them.

Environment

• Claude Desktop 1.18286.0 (Electron 42.5.1)
• macOS (Darwin 25.5.0)

Symptom

• The Remote Control panel shows two rows: workspace — <project>, each stuck at 0 of 32.
• Both point at the same workspace/host and appear to be orphaned remote-session records left over after the underlying sessions ended.

What I tried

• Full quit (killall Claude) + relaunch — the entries come back.
• Deleted the matching local claude-code-sessions/*.json records, then relaunched — no effect.
• Verified the entries are not stored in any local store: Local Storage leveldb, IndexedDB, config.json, claude_desktop_config.json. The list appears to be re-fetched from the server on each launch, which is why local deletion / cache clearing does nothing.
• Hovering a row offers "End session" only when a session is active; for these ghosts there is no delete / remove / disconnect control.

Expected

A way to remove or dismiss an orphaned remote session whose backing process no longer exists — e.g. a per-row remove control, or automatic server-side expiry of dead sessions.

[juliabeach]

Same on macOS (Darwin 25.5.0), Claude Code CLI 2.1.193. Additional repro detail on the session-identity fragmentation:

Launching claude in the terminal with remoteControlAtStartup enabled, then going through a teleport + /remote-control round-trip (hitting the desktop /remote-control init failure from #48238), leaves behind slug-named "Working" stubs with zero messages.

Confirmed inert: 0% CPU, no assistant turns in the session .jsonl, no disk writes — so they are not consuming any quota, just stuck status flags.

Pressing ← into agent view surfaces the real (correctly-titled) session as a distinct entity, which proves the "Working" slugs are orphaned registration records left behind, not the live session. Local .jsonl deletion has no effect (server-side, as already noted here).

Related: #48238, #42589, #32992.

[johntaurog-wq]

Edit: there is a working fix — see the bottom of this comment. My original version claimed deletion wasn't possible; that was wrong. Leaving the diagnostics up because they still explain why these sessions are unrecoverable, and the missing-delete gap is real on mobile.

---

Hit this on v2.1.215 with three orphaned Remote Control sessions. Posting the diagnostics because the resume error points at a specific root cause.

Symptoms

Three sessions in the mobile app's Code tab, all permanently Disconnected, dated ~2.5 weeks ago. Each still showed background Shell tasks as running, with elapsed counters that kept incrementing — ~21,344 minutes (≈14.8 days). The stop button on each task was a no-op.

Verified on the host machine: nothing was actually running. No matching processes, no listening ports, zero CPU. The Mac had been rebooted several times since. The counters were purely stale server-side state.

Resuming them fails with a specific error

Since v2.1.200 added --session-id, I tried reattaching to each:

$ claude remote-control --session-id session_01VzxySHFTFJmJQdFFipfRnz
Error: Session session_01VzxySHFTFJmJQdFFipfRnz has no environment_id. It may never have been attached to a bridge.

Identical for all three (session_01VzxySHFTFJmJQdFFipfRnz, session_01YS3nJwW95tCCkLJqq58ReE, session_016MMVbhbGzH2zL5kYR1F9aT).

So the server has a record for each, but with no environment_id — never bound to a bridge. These aren't sessions that died; they're records that were never fully established.

That matches the documented pre-2.1.200 behaviour:

Before v2.1.200, a reconnection failure created a new Remote Control session instead of showing this message, which left extra sessions in the session list at claude.ai/code.

Which also explains three separate entries, with three different auto-generated names, for what was one piece of work.

Every symptom follows from the missing environment_id

Symptom	Cause
Always Disconnected	No bridge was ever attached
Stop button is a no-op	No environment to route the signal to
--session-id can't reattach	No environment to reattach to
Task counters never stop	Nothing can mark them complete

✅ The fix: delete them from the web UI

They can be deleted — just not from the mobile app. At claude.ai/code in a browser, the ⋮ menu on each session row has an Delete entry (alongside Archive). It works on these orphaned records, environment_id or not. All three are gone.

If you're stuck on this, that's the answer: use the browser, not the phone.

What's still worth fixing

1. Delete is missing from the mobile app — it only offers Archive. Anyone who lives in the mobile app (which is the natural place to notice orphaned sessions) has no way out and reasonably concludes there isn't one.
2. Server-side reaping of records with no environment_id. They can never become usable, so they could be garbage-collected instead of accumulating.
3. No local way to enumerate remote session IDs. They're only recorded in transcripts as {"type":"system","subtype":"bridge_status"} events, and orphans from the reconnect bug never wrote one. I had to read them out of the browser address bar (claude.ai/code/session_…) to test any of this.

Environment

• Claude Code 2.1.215 (CLI), Desktop app 1.7196.3
• macOS 26.4.1 (build 25E253), Apple Silicon
• Max plan, claude.ai OAuth

[kimyc92]

Same symptom here on macOS. Two data points that I don't think are in the thread yet.

1. The web UI has the same gap, so this isn't desktop-only.

The environment picker at claude.ai/code shows the identical list, and hovering a dead row only highlights it. Reading the accessibility tree, each remote-control entry is a bare menuitemradio with no child elements — there is no hidden control to reveal. By contrast, session rows in the sidebar do expose a "more options" button. So environments appear to have no management affordance implemented on either surface.

2. The desktop panel and the web list disagree, and the desktop is the one that's lying.

I had 4 claude remote-control processes running (one per repo) plus 3 stale entries left over from a reboot — 7 total in both UIs. Two of the processes then exited on their own after sitting idle with no attached session. The desktop panel dropped to 5. The web list still showed 7.

So a graceful exit does not deregister anything server-side; the desktop panel just stops showing entries whose local process it can no longer see. That means the server-side registration count keeps growing even when the desktop panel looks clean, and a user has no way to tell how many are actually accumulated. It also explains why quitting and relaunching the app doesn't help — the list is re-fetched, and the server still has all of them.

Repro

1. Run claude remote-control in a few different directories.
2. Reboot (or kill the processes ungracefully) so they never deregister.
3. Start them again — the old registrations are not reused; new entries are appended.
4. Ghost entries remain in the web list indefinitely, with no way to remove them from the desktop app, the web UI, or the CLI (claude remote-control --help has no list/revoke/cleanup option).

Environment

• Claude Desktop 1.24012.11
• Bundled Claude Code CLI 2.1.219
• macOS (Darwin 25.6.0)

Either a per-row remove control or server-side expiry would solve this; right now there is no path at all.

[ysollo]

+1, hitting this too. Using the device-pairing flow (claude remote-control --name X) with an auto-restart wrapper script around it (loop that reattaches with -c after network drops) — every time the terminal window gets closed without explicitly disconnecting from the panel first, a new ghost entry sticks around. I'm at 20+ dead entries now, and since each project directory only ever shows its live session tangled in with all the dead ones, the picker for a single 2-directory setup is basically unusable. A per-row remove action (or a bulk "clean up disconnected") as requested above would fix it — server-side expiry for anything with no backing process would also work without needing a UI change.