New Local-main sessions replace prior conversations, creating high potential data-loss risk

[karelz]

Short summary

Creating a new Local-main session replaces the prior resumable conversation, creating high potential data-loss risk

Affected version or release

GitHub Copilot app 1.0.83-5

Installation context

Local Windows workspace in the GitHub Copilot app. The project was karelz/Misc, using the existing checkout at C:\github\copilot-repos\Misc on branch main with the Local-main workspace option. The exact Windows version was not captured.

What happened?

I explicitly selected or created a new session using Local-main three times for the same repository checkout. Three distinct underlying CLI conversation records were created, but the app exposed/reused a single Local-main sidebar/project session rather than preserving three separately resumable discussions.

Later session creation replaced the previously visible discussion and name. The older discussion was no longer visible in the UI, although its underlying record remained in local database history and was recoverable through a separate session used to repair the state. The final exposed session used identity 24b63b59-da8d-463b-92f6-3e2052902143 and was displayed as Service host machines, even though that underlying record had the summary Session "Service host machines" got stuck, can you help?.

It is expected that branch-mode Local-main sessions share one checkout and therefore share its source-control state. The bug is that an explicit new-session action silently reused/replaced the existing resumable conversation instead of creating a distinct conversation or warning that only one session can own that checkout.

This created a high potential data-loss risk. Unrelated work became entangled in the shared checkout: two committed Copilot-instruction changes on local main, 10 staged Service Host/MsrcMonitor files, and temporarily an unmerged index entry in Utils\ServiceHost\src\Program.cs after a rebase. No work was permanently lost, but only because manual recovery happened before the shared checkout changed further.

The behavior occurred on three consecutive explicit Local-main session creation attempts, making accidental user error or a transient sidebar refresh unlikely.

Steps to reproduce

These steps describe the observed incident:

1. Open a repository project with an existing local checkout on main.
2. Create a new session using Local-main and begin a discussion or task.
3. Explicitly create another new session using Local-main for the same repository and checkout.
4. Give the new session a different task or discussion.
5. Repeat the new Local-main session action a third time.
6. Inspect the sidebar/project sessions and try to resume each discussion independently.
7. Compare the visible project session identity with the underlying CLI conversation records.

Observed result: three underlying conversation records exist, but only one Local-main sidebar/project session is exposed. Later creation replaces the prior visible discussion/name without warning.

Expected behavior

Creating a new Local-main session should never silently replace or reassign an existing resumable conversation.

Either:

1. Each successful explicit new-session action should create a distinct, stable conversation identity that remains independently visible and resumable, while clearly indicating that repository state is shared with other branch-mode sessions using that checkout; or
2. If only one Local-main session can own a checkout, the app should block or redirect duplicate creation with a clear warning and offer to resume the existing session or create an isolated worktree session.

Session display names, sidebar entries, project-session IDs, and underlying CLI conversation records should remain consistently mapped. The UI should clearly distinguish conversation isolation from checkout isolation.

Additional context

Incident date: 2026-09-07.

Distinct underlying CLI conversation records:

Record ID	Approximate time (UTC)	Summary
fa0d8f46-dde2-4dd3-9335-5adf13efb352	07:26	Service host machines
2a157096-be51-43e3-9a44-d69e4cd4a6d4	07:40	Update Copilot instructions
24b63b59-da8d-463b-92f6-3e2052902143	07:59	Session "Service host machines" got stuck, can you help?

All three targeted C:\github\copilot-repos\Misc on branch main.

Recovery required:

1. Forensic inspection of local session records to reconstruct the three task boundaries.
2. Exporting staged Service Host/MsrcMonitor changes with git diff --cached --binary.
3. Verifying the exported 23,267-byte patch.
4. Creating separate worktree sessions.
5. Applying and staging the patch in the Service Host session.
6. Cherry-picking the exact instruction commits into a separate instructions session.

Recovery produced standalone worktrees/branches for Service Host machines, Update Copilot instructions, and stuck-session recovery.

An earlier request on 2026-09-01 described Local-main as an isolation-risk/default-UX concern, but I found no confirmed filed issue. Searches of open and closed github/app issues for Local-main session reuse, conversation replacement, shared checkouts, and related data-loss terms did not surface a duplicate.

[brandonmartinez]

Confirming this on macOS (app 1.1.15, bundled CLI 1.0.83-5) — same behavior, and I can add the client-side cause: the app explicitly asks the backend to reuse the existing workspace.

The client sends existing_workspace_id

Comparing two ensure_session_warmup payloads sent ~35s apart in the same project, from the app's own websocket log:

// worktree session -> new workspace created
{"workspace_type": "worktree", "base_branch": "main"}

// Local/branch session -> reuse requested by the client
{"workspace_type": "branch",
 "existing_workspace_id": "<the one pre-existing Local workspace>"}

Three consecutive New Session clicks (three distinct composer_ids) each carried the same existing_workspace_id. So the backend isn't inferring the match from title, branch, or cwd — the UI names the workspace to reuse. Deterministic, 3/3.

Result: N conversations, one exposed session

All four sessions were aliased onto a workspace created 8 days earlier:

3f283d07  "Remote vault search"                       2026-08-30   <- original, gave the workspace its name
a2b469c4  (untitled)                                  2026-09-06
f6308235  "Testin to see if this spins up a new ses"  2026-09-07
45e3e721  "this is another test to see if it spins"   2026-09-07

Matching your observation that the exposed session displayed a name from a different underlying record: sessions.title is generated correctly per conversation (title_source='auto', values above), but the header and sidebar render workspaces.name, which is written once at workspace creation and never revised. So every later session inherits the first task's title.

Confirming the data-loss framing

History isn't overwritten on disk — each session keeps its own events.jsonl (21 events vs 219 for the 8-day-old one). But it becomes unreachable through the UI, which matches your "recoverable only through a separate repair session."

Checking my whole install for how widespread that is — sessions with no workspace binding at all, so they cannot render in the sidebar under any filter:

project sessions with no workspace alias: 701
  no state dir (warmup churn, harmless):  656
  dir but empty events.jsonl:               9
  HAS real conversation content:           36   <- orphaned, on disk, unreachable

36 real conversations exist on disk that the UI cannot reach. That's the data-loss surface, and it's silent — nothing warns that a new session joined an existing workspace instead of getting its own.

Also a behavior change, not a longstanding limit

I have 11 non-archived workspace_type='branch' workspaces on one project's main, oldest 2026-08-07 (another reporter in #3586 has 74, back to June). The app clearly used to create many Local workspaces per project.

Only branch workspaces accumulate multiple unrelated sessions; worktree is 1:1 in every observed case:

workspace_type  workspaces  sessions  avg_per_ws  max_in_one
branch          15          16        1.07        2
worktree         2           2        1.0         1

Worktrees aren't a workaround for this class of project

My case is a personal Obsidian vault: the notes must stay at one fixed path so the Obsidian app and the sessions see the same files. A worktree makes a detached copy and breaks that, so Local/in-place is the only viable type. Same constraint reported in #3586.

Suggestions

1. If one Local workspace per project is intentional, say so in the UI when a new session joins an existing workspace — silent reuse is what makes this feel like data loss.
2. Don't pin workspaces.name to the first session's title. Name the shared checkout neutrally (<project> (main)) or let it follow the active session.
3. Keep prior conversations reachable — a workspace holding N sessions should expose all N, not just the newest.

Archiving the stale workspace does appear to release the reuse target: after archiving mine, the next Local session got a fresh workspace.

Related: #3586, #3535, #3562, #3530. Separately I filed #3575 for a ~30s stall in session.create on this same build (was 0.6–0.9s), which compounds this — the warmup pool can't refill, so New Session more often lands you in the previously focused session.

[brandonmartinez]

This appears to be resolved in 1.1.16