Branch-type sessions all get updated_at bumped on any git checkout, flooding the sidebar

Start by tracing the checkout synchronization that propagates branch values to sessions stored in ~/.copilot/data.db, then follow how the sidebar orders sessions by updated_at. Done means a git checkout preserves genuine session ordering while keeping branch state synchronized; the issue lists several possible fixes, so the final approach requires maintainer guidance.

Summary

Every git checkout in a repo that backs workspace_type = 'branch' sessions rewrites workspaces.updated_at for all sessions bound to that checkout. The sidebar sorts by updated, so a single branch switch pushes 60–70 stale sessions to the top and buries the sessions I was actually working in.

The sidebar has no sort control, so there is no way to work around this from the UI.

Environment

• GitHub Copilot CLI 1.0.84-5 (desktop app)
• Windows
• 158 active sessions: 140 branch, 18 worktree

Reproduction

1. Create several "Local" (non-worktree) sessions against the same local repo, so they share one checkout. They are all stored as workspace_type = 'branch'.
2. In that repo's working directory, run git checkout some-other-branch.
3. Open the sidebar.

Expected: session ordering is unchanged. I did not interact with those sessions, so they are not more recently "updated" in any sense the user cares about.

Actual: every session bound to that checkout jumps to the top with a fresh timestamp, ordered arbitrarily among themselves. Genuinely recent sessions are pushed far down the list.

Evidence

From ~/.copilot/data.db, grouping active sessions by update minute — two distinct mass-update bursts, each completing in ~300 ms:

updated_at (minute)  | rows
---------------------+------
2026-09-16T16:50     |   66
2026-09-10T16:37     |   62

The 16:50 burst spans 16:50:37.754Z → 16:50:38.071Z. The corresponding git reflog entry in the shared checkout:

checkout: moving from production to features/<redacted>   @ 2026-09-16 12:50:36 -0400  (= 16:50:36Z)

The checkout lands ~1.5 s before the burst. All 66 rows are workspace_type = 'branch' pointing at that one checkout, and all now carry the identical branch value. Today the same query shows 69 rows collapsed onto the current branch name:

branch                       | rows
-----------------------------+------
features/<redacted>          |   69

So the branch column is denormalized onto every session row sharing the checkout, and keeping it in sync is what stamps updated_at.

Why this is a bug, not just cosmetics

updated_at is doing double duty: it is both an internal row-version/bookkeeping field and the user-facing "last activity" sort key. A background sync that reflects the checkout's state change is being recorded as user activity on 69 sessions. Those two concepts need to be separate.

The severity scales with session count, and it is self-reinforcing: the harder the list is to navigate, the more likely you are to create yet another session instead of finding the existing one.

Suggested fixes

Any one of these would resolve it; the first is the real fix.

1. Separate the timestamps. Keep updated_at as a row-version field and add a distinct last_activity_at that advances only on actual session activity (user message, agent turn, session open). Sort the sidebar by that.
2. Don't stamp on no-op syncs. When propagating a checkout's branch to bound sessions, write the branch without touching updated_at — or skip the write entirely when the value is unchanged.
3. Normalize the branch. For branch-type sessions the branch is a property of the shared checkout, not of each session. Read it through the checkout rather than copying it onto every row.
4. Give the sidebar a sort control (Created / Updated / Name / Pinned). Useful regardless, and the only one that helps users who already have this problem. The full session list view can sort by Created; the sidebar cannot, which is the gap.

Workarounds (both unsatisfying)

• Use Worktree sessions instead of Local ones, so each has its own branch. Doesn't help sessions that already exist.
• Bulk-archive the stale sessions. This is what I ended up doing — 140 of 158 — but it's a lot of manual right-click-archive, and it discards history I'd rather keep just to make the list navigable.