Desktop app: second machine's sidebar keeps listing archived/ended sessions (survives app restart)

Summary

I run Claude Code Desktop signed into the same account on two Macs (a MacBook and a Mac mini), linked via Remote Control. Sessions that are long finished/archived on one machine continue to show up as live entries in the other machine's project sidebar — and restarting the app on the affected machine does not clear them.

Environment

• Claude Code Desktop (macOS), same account on both machines
• Two machines linked via Remote Control: "mbp" and "mini"
• Affected view: the per-project session list in the sidebar (e.g. the group for the ~/.claude config repo)

Steps to reproduce

1. Start several sessions from machine B (mini) via Remote Control from machine A (mbp).
2. Let those sessions finish and get archived (either explicitly, or by ending normally).
3. On machine A's (mbp) sidebar for that project, the finished sessions correctly disappear from the active list.
4. On machine B's (mini) own sidebar for the same project, the same finished sessions are still listed as if active — they do not disappear.
5. Restart the Claude Code app on machine B (mini). The stale entries are still there after restart.

Expected behavior

Both machines' sidebars should reflect the same canonical archived state for a session, and a restart should at minimum force a fresh fetch that clears stale entries.

Actual behavior

Machine B's (mini) sidebar accumulates stale entries over time and does not self-heal, even across an app restart.

Evidence gathered from inside a session on machine A (mbp)

Using the CCD session-management tools available to a Claude Code session:

• list_sessions (the canonical, account-wide session store) has no record at all for the stale titles shown in machine B's sidebar — not even as isArchived: true. They're simply absent from the store the tool queries.
• search_session_transcripts finds no transcript of their own for these titles either — only incidental mentions inside other, unrelated sessions' tool-output history (because those other sessions had called a peer-listing tool at some point and happened to see the same stale roster).
• Attempting to message these sessions directly (cross-session messaging over Remote Control) fails for all of them with HTTP 409 — that Remote Control session may have ended or disconnected.
• A peer-listing tool call (which surfaces the Remote Control presence roster) shows the same stale entries and they accumulate further over time — a call made ~20 minutes after an earlier one showed several additional stale mini-machine entries that weren't present before, while genuinely still-active sessions correctly show as reachable.
• One title (a recurring task name reused across days) appeared twice in historical tool output with two different internal refs at different timestamps (one from the previous evening, one from the following morning) — i.e. this isn't one entry stuck once, it's the pattern recurring and accumulating rather than being pruned.
• By contrast, machine A's (mbp) own sidebar for the same project, and the list_sessions tool, both stay clean and agree with each other — only genuinely still-running sessions are listed.

This points at machine B's (mini) sidebar — and the underlying Remote Control presence roster it (and the peer-listing tool) reads from — never receiving/processing the "this session ended/was archived" event, so entries pile up indefinitely instead of being pruned, and a plain app restart doesn't force a resync against the authoritative session list.

Impact

Low severity (cosmetic/stale UI, not data loss) but confusing — it looks like archived sessions "come back" on the second machine, and there's no user-facing way to clear them short of (apparently) whatever this issue's fix would be, since a restart doesn't help.