`cwd` and `branch` no longer persist to local session-store.db since ~1.0.13

[bscheurm]

Describe the bug

Since approximately version 1.0.13 (March 29), the cwd and branch columns in the local ~/.copilot/session-store.db sessions table are NULL for the majority of new sessions. The data is correctly captured in workspace.yaml files under ~/.copilot/session-state/{session-id}/, but it is not being written to the SQLite database.

Evidence

Daily NULL rate for cwd in the sessions table:

Date	Sessions	NULL cwd	Rate	Notes
Mar 25–28	40	0	0%	Healthy baseline
Mar 29	22	17	77%	Sharp inflection — 17 zero-turn "ghost" sessions at 19:37 UTC (auto-update restart signature)
Mar 30–31	22	11	50%	Intermittent — some sessions still populated correctly
Apr 2–3	25	22	88%	Stabilized high
Apr 5–12	77	71	92%	Consistently broken through current (1.0.24)

branch follows the same curve. summary, turns, session_files, and other tables appear unaffected based on spot-checking — only cwd and branch in the sessions table show the regression pattern.

Root cause hypothesis

The 1.0.13-2 changelog (released as a pre-release around March 29–30) includes:

"Reduce CLI startup time by running terminal detection, auth, and git operations in parallel"

If the session row is inserted into SQLite before the async git discovery completes, cwd and branch would be NULL in the database. The workspace.yaml files (written by a different code path or updated after git discovery) correctly contain:

cwd: C:\Users\<user>\source\<project>
git_root: C:\Users\<user>\source\<project>
branch: master

This is consistent with a race condition introduced by the parallelization.

Verification that this is not self-inflicted

• No custom scripts or tools write to session-store.db — all local tooling is read-only (verified via code audit)
• SQLite WAL is healthy — checkpoint succeeded, no lock contention
• No external processes (OneDrive sync, antivirus) touch the .copilot directory
• The sessionSync config change to "local" (April 10) did not cause a second regression — cwd was already broken by then

Steps to reproduce

1. Install Copilot CLI 1.0.13 or later
2. Start several sessions in a git repository over the course of normal use
3. Query the local session store:

   import sqlite3
   from pathlib import Path
   conn = sqlite3.connect(str(Path.home() / '.copilot' / 'session-store.db'))
   for r in conn.execute("SELECT id, cwd, branch FROM sessions ORDER BY created_at DESC LIMIT 20").fetchall():
       print(r)

4. Observe that the majority of sessions have NULL cwd and branch (in my case, ~78–92% since March 29)
5. For a NULL session, check the corresponding workspace.yaml:

   cat ~/.copilot/session-state/{session-id}/workspace.yaml
   

6. Observe cwd and branch are correctly populated there

Impact

• Local session queries are broken. Any tooling querying session-store.db for sessions by working directory or repository gets incomplete results. ~78% of sessions since March 29 are affected (125+ sessions in my case).
• Session resume grouping. The 1.0.18 changelog notes "Session resume picker correctly groups sessions by branch and repository" — this likely can't work correctly when the underlying data is NULL.
• Third-party tooling. Users who build automation on top of session-store.db (workstream tracking, session digests, stale work detection) lose the ability to filter or classify sessions by repository.

Recovery

A backfill is possible since workspace.yaml has the correct data. A script could read each ~/.copilot/session-state/{id}/workspace.yaml and UPDATE the corresponding sessions row in SQLite.

Environment

• Copilot CLI: 1.0.24 (regression started in 1.0.13-x timeframe)
• OS: Windows 11
• Local session-store.db: 614 sessions, 125 with NULL cwd (all post-March 29)
• workspace.yaml files: correctly populated for all sampled NULL-cwd sessions

Additional note: repository column

Separately from this regression, the repository column in the sessions table has been ~83% NULL for the entire history of the local DB — including the healthy pre-March 29 period. This may be by design (perhaps only populated in the cloud session store), but if it's intended to hold the git remote URL, it appears to have never worked locally. Mentioning in case it's related to the same code path.