[BUG] Open Code session in no sidebar group, including Ungrouped
Description
Open (non-archived) Code sessions can end up in no sidebar group at all — not in any custom group, and not in "Ungrouped" either. The session still exists and is fully open (confirmed via the session-management MCP tools: isArchived: false), but there is no way to find or reach it from the sidebar.
This is distinct from #70312 (sessions missing after machine migration) — this happened during ordinary same-machine use, with no migration, account switch, or update involved.
Steps to reproduce
Hard to reproduce deliberately — found by auditing sidebar contents against the session-management API. What I can confirm:
- Session titled "Return moms id and wallet", last active 2026-08-12,
isArchived: false. - Not visible under any custom group in the sidebar.
- Not visible under "Ungrouped" either (checked the full Ungrouped list against the session, no match).
- Confirmed to still exist and be open via the session-management MCP tools before archiving it manually to resolve.
A second session ("Op meter curve analysis", last active 2026-08-03) showed the same symptom — open, but absent from every visible group including Ungrouped.
Expected behavior
Every non-archived session should be reachable from the sidebar — either under a group it was assigned to, or under "Ungrouped" as a fallback.
Actual behavior
Some open sessions are in neither. They're invisible in the UI entirely, with no error, no orphan/uncategorized bucket, and no indication anything is missing. The only way I found them was by comparing the sidebar against session data via API/MCP access.
Environment
- Claude Code Desktop
- macOS (Darwin 24.6.0)
- Discovered 2026-08-15
Additional context
This seems related to the broader family of "sidebar state drifts from underlying session data" bugs (e.g. #70312, #25524, #58193), but those are attributed to migrations, updates, or account switches. This occurred with none of those triggers — just ordinary session creation and archiving over time. Possibly related to how a session's group assignment is stored/read, but I don't have visibility into that internal state.