Orphaned remote-control bridge sessions force folder-name disambiguation suffix in Code sidebar and cannot be viewed or deleted from any UI

Environment:

• Claude Code desktop app, macOS (Darwin 25.6.0), account with two devices
• Device A: MacBook Pro, projects vault at ~/Documents/IA (folders NN_Name)
• Device B: Ubuntu VPS (hostname srv1829998) running claude remote-control --name espantalho-vps --spawn=same-dir as a systemd service; CLI version 2.1.227 at the time the sessions were created

Summary:

The Code sidebar groups conversations by cwd basename per machine and appends the parent path to disambiguate when two groups share a name (e.g. 41_Automacao_VPS-Hermes-GITHUB · ~/Documents/IA). A claude remote-control instance registers a session server-side as soon as it starts (it writes bridge-pointer.json locally), even with zero conversations.

After the systemd units were removed and all local state was cleaned (~/.claude/projects/<key> deleted on the VPS), those server-side registrations persist and still force the disambiguation suffix on the other device's homonymous groups — but they render no group and no conversation entry in ANY surface, so there is nothing the user can click to delete:

• Desktop sidebar: only the Mac group renders (with the suffix); no adjacent twin group appears.
• Desktop search: no hits for the orphaned conversation's first message.
• iOS app: sessions visible in the Code tab offer no delete for these.
• claude.ai/code: sidebar search for the VPS hostname srv1829998 returns nothing.
• CLI: claude project purge --dry-run shows the command is local-only (transcripts, tasks, ~/.claude.json entries); claude --cloud <bridge_session_id> returns Session not found.

Reproduction (as observed):

1. Device A: open folder ~/x/FOO in the desktop app (creates group FOO).
2. Device B: run claude remote-control with WorkingDirectory=/other/path/FOO long enough for bridge-pointer.json to be written; then stop the service, remove the unit and delete ~/.claude/projects/-other-path-FOO.
3. Device A: group FOO permanently shows FOO · ~/x, and no UI lists any session from device B to delete.

Control case: on the same account and day, Mac folders that never had a VPS-side session (39_…, 40_…) show no suffix; the three that had one (37_…, 38_…, 41_…) all show it. An app restart (Cmd+Q) does not clear the suffix.

Orphaned session IDs (account identifiers available to Anthropic staff on request):

• session_019YsUbMLMHZdyJvwdxMfyfr (env env_01YKYJRKPKmBmcKguFN7LXc2) — bridge only, zero conversations (folder 37_Afiliados)
• session_01NeE4ZwHwf9m9MpxaAPqn32 (env env_01EieQPYdQnNCNAbaW4uSyvM) — plus 3 orphaned conversations (folder 38_Oraculo-Interno)
• session_01KdT5bpvo3g6k7UZL2eGyMC (env env_011mPdCb9N36JdR4zGJwkz6u) — plus conversation 0d8fca41-85c8-4c64-bccf-a1b388dbe364, created 2026-08-14T20:30Z (folder 41_Automacao_VPS-Hermes-GITHUB)

Expected behavior: either (a) orphaned bridge registrations expire or stop counting toward name disambiguation once their device state is gone, or (b) they are listed somewhere (app or claude CLI) so the user can delete them.

Happy to provide journalctl output, the tarball of the pre-cleanup ~/.claude/projects keys, or timestamps for any of the sessions above.