Desktop sessions become permanently unreachable ("Remote Control disconnected") after going dormant, with no local transcript cache

Environment: Windows 11, Claude Code desktop app, single local machine (no other hosts involved).

Symptom: A session shows full scrollable history in the sidebar but can never reconnect. Banner: "Claude Code on the computer running this session is offline... if Claude Code was closed, start it there again and reopen this conversation." Fully quitting and relaunching the desktop app — repeatedly, over time — does not restore it. This has happened to many sessions over time, not a single incident.

Trigger pattern: this consistently happens to sessions I've let go dormant (not touched for a while) and then come back to resume later — not to sessions in active, continuous use.

Workaround (lossy): abandon the session, or manually copy its visible content into a new one.

What I found investigating two current stuck sessions:

• Session enumeration via the app's own session-listing undercounts real sessions substantially (~20-25 surfaced vs 37 actual .jsonl transcript files for one project alone) — the two stuck sessions don't appear in it at all, live or archived.
• Unlike other sessions, no .jsonl transcript for either stuck session exists anywhere under ~/.claude/projects (searched the full tree, using exact strings from the session's own prompts) — so unlike a normal local session, there's nothing to recover from disk.
• ~/.claude/projects/<project>/bridge-pointer.json is a single file per project (not per-session), which seems like it could only track one "standalone" environment binding at a time per project directory — possibly relevant to why concurrently-open sessions in the same project lose their reconnect path, but I couldn't confirm the mechanism from the client side.

Impact: repeated, unrecoverable loss of long-running work sessions with no user-facing way to diagnose or fix it, specifically tied to letting a session sit idle before returning to it.

I can share the specific session names/IDs in private correspondence if that helps debugging — leaving them out of this public report.