[Bug] CLI-created sessions never appear in the Desktop task sidebar — only 88 of 347 sessions in the shared store are visible (0.16.5 macOS)

Pre-submission checklist

• I searched existing Issues and Discussions; closest are #583 / #379 (queue promotion/discard), but those cover queued messages — this report is about sessions themselves never appearing in the Desktop UI.
• I read CONTRIBUTING.md.
• User message bodies, local username, workspace paths and full session/trace IDs are omitted or sanitized.

Category

Desktop app / session list & task sidebar sync (CLI ↔ Desktop shared session store)

Agent framework

ZCode Agent（自研 / first-party）

Severity

High. Roughly three quarters of all sessions in the shared session store are invisible in the Desktop app: no history, no way to open/resume/archive them from the UI.

Reproducibility

Always. Measured on 2026-09-12, ZCode Desktop 0.16.5 + CLI 3.11.2, macOS 15 (arm64).

Steps to reproduce

1. Use the CLI the way it is designed to be used: run zcode in a terminal for day-to-day work, and/or invoke headless turns (zcode --resume <sid> --prompt ...) from scripts/automation.
2. Open the Desktop app and look at the task sidebar / session list.

Result: sessions created or driven by the CLI are persisted to the shared session DB, but never get a task entry in the Desktop index — they simply don't exist for the UI.

Measured evidence (same machine, same store):

sessions in session DB:        347   (all with real messages, 0 empty shells)
task entries in Desktop index:  91
sessions with a task entry:     88
sessions invisible in Desktop: 260  (~75%)

The invisible set includes sessions with activity minutes before the measurement, so this is not just stale leftovers — every CLI-driven session is affected.

Use case

CLI and Desktop share one session store, and headless --resume turns are an official workflow (they're even how the queue in #583 gets drained). But the work done that way is unreachable from the Desktop app: the user can't find the session, can't resume it with the UI, can't manage its queued messages, and can't archive/clean it up. This also amplifies #583/#379 — when a queue gets stuck or discarded, the user often can't even see the affected session in the sidebar.

Request

Make every session in the shared store visible in Desktop, e.g. one of:

1. On launch (or lazily), backfill task entries for sessions the Desktop app didn't create itself;
2. Or add an "All sessions" view that lists everything present in the session DB (workspace, last activity time), with open / resume / archive actions.

Either way the invariant should be: a session that exists in the store must be reachable from the UI.

Happy to provide schema-level detail (table/column names, counts per workspace) if useful.

Compare the shared session DB contents with the Desktop task index using the reported counts, including recently active CLI and headless sessions. Trace how Desktop-created sessions receive task entries and decide whether launch-time backfill or an all-sessions view best enforces the stated invariant; done means every session in the store is reachable and manageable from the UI.