New session in Local mode reuses an existing entry and replaces its conversation/history association

[ShawnXxy]

Short summary

Starting a new session from a project's sidebar New session button can create a fresh conversation under a pre-existing session/workspace entry. The old entry keeps its title and pull-request association, but displays the new conversation instead of its original history.

The original transcript remains on disk; this appears to be an incorrect conversation association rather than confirmed transcript deletion.

Affected version or release

GitHub Copilot desktop app 1.1.15. Bundled CLI version: 1.0.83-5.

Installation context

Windows 11 Pro, version 10.0.26300, build 26300; per-user desktop installation.

The affected project is a local Git repository. Sessions use the existing checkout, with workspace_type: "branch" / Local mode, not separate worktrees. The project already has several older Local sessions sharing that checkout. The affected entries included completed work with merged PR associations.

What happened?

On September 7, 2026, requesting a new session instead opened a fresh conversation under an existing entry. The old name and PR association remained, while the earlier conversation appeared missing.

Two existing entries were affected during the initial incidents. Their stored transcripts were still present. After a backed-up repair of the conversation associations, the same release-related entry was affected again by another new-session request.

Read-only inspection of the local app database during the recurrence showed:

Record	Observed value
Existing workspace creation date	August 31, 2026
Existing workspace's current session_id	A new conversation created September 7, 2026
Original conversation alias	Still points to the existing workspace
New conversation alias	Also points to that same existing workspace
Original transcript	Still present under its original session-state directory

The behavior occurred before any manual repair. The repair restored the older conversation association and separated the new conversation into its own entry, without changing transcript contents, PR links, app binaries, or repository files. This was data recovery, not a fix for the recurrence or a recommended user workaround.

Steps to reproduce

These are the observed steps in the affected existing profile; a clean-profile minimal reproduction has not yet been established.

1. Open a local repository project that already has older Local/branch sessions using its existing checkout.
2. Click the project's sidebar New session button, intending to start an independent conversation.
3. Use Local/existing-checkout mode and submit a prompt.
4. Observe that the fresh conversation is shown under an older session entry, with that entry's existing title/PR association, rather than as independently addressable new history.
5. Reopen the older entry: its previous conversation is no longer the one displayed, even though its transcript still exists locally.

This occurred repeatedly in the affected profile, including after a prior association recovery. It has not been established whether every project/profile, another execution mode, or another operating system is affected.

Expected behavior

Starting a new session should preserve the independently accessible history and identity of existing sessions. It should not silently replace the conversation displayed by an old entry or inherit that entry's unrelated PR association.

If Local mode intentionally permits only one workspace for a project, the UI should make that constraint explicit and preserve access to earlier conversations rather than making a new-session action appear to erase their history.

Additional context

The following are sanitized, normalized excerpts from the recurrence's app log. Repository paths, project IDs, workspace IDs, conversation IDs, and composer IDs are replaced with consistent placeholders. Omitted request fields and full debug logs are not included because they may contain sensitive information.

2026-09-07T11:44:54.752609Z
  received message: ensure_session_warmup
  composer_id: C_NEW
  config.project_id: P
  config.workspace_type: branch
  config.existing_workspace_id: W_EXISTING

2026-09-07T11:44:54.836847Z
  github_app::handlers::session
  Received create_session request
  cwd: <REPO_PATH>
  workspace_id: W_EXISTING
  session_type: Project

2026-09-07T11:44:55.646270Z
  github_app::session::manager::lifecycle
  creating new session
  cwd: <REPO_PATH>
  account_scope: Workspace(W_EXISTING)

2026-09-07T11:44:59.035517Z
  received message: submit_session_warmup
  composer_id: C_NEW
  config.workspace_type: branch
  config.existing_workspace_id: W_EXISTING

These records show that the new-session flow supplied an existing workspace ID during warmup and submission, and session creation ran against that workspace. They do not establish why the UI chose that ID, whether persisted UI state contributed, or which implementation change would be correct. No app-routing source code has been inspected.

Potentially related reports: #3530 and #3592 describe the active-Local-workspace restriction on the same app version. This report is specifically about an existing entry's conversation/history association being replaced, rather than session creation failing with that restriction. A common root cause has not been confirmed.

No raw transcripts, credentials, full database files, or unsanitized debug bundles are attached.

[rumukh]

Independent reproduction of the same behavior on GitHub Copilot app 1.1.15 (commit b5f4206), Windows x64, bundled CLI 1.0.83-5.

The affected project uses a local repository's existing checkout (workspace_type: "branch"). I clicked the project's + / New session control and submitted a new, unrelated prompt. The new conversation appeared under an older session entry, retaining its old title and replacing the history displayed there.

This happened with two successive new-session submissions. The older entry in this reproduction did not have an associated PR, so the symptom is not limited to PR-associated sessions.

Independently observed evidence

Read-only inspection of the app log and local database showed:

• Both new-session submissions included config.workspace_type: "branch" and config.existing_workspace_id: W_EXISTING.
• The session-creation handler and lifecycle ran against W_EXISTING and allocated new conversation IDs.
• That existing workspace's current session_id changed to the new conversation.
• The original and new conversation IDs remained aliases of the same workspace. Opening or looking up the original session ID therefore resolved to the newer conversation.
• The original session row, original transcript, and its artifacts remained present. The original transcript did not contain the unrelated new prompts; those were stored in the separate new transcripts.

Normalized relevant request shape, with identifiers and prompt contents removed:

{
  "type": "submit_session_warmup",
  "config": {
    "kind": "project",
    "workspace_type": "branch",
    "project_id": "P",
    "existing_workspace_id": "W_EXISTING"
  }
}

The same existing workspace was already passed to session creation during warmup, before the new prompt was processed by the model. These observations localize the symptom to existing-workspace selection/rebinding; they do not establish the exact frontend condition or a source-level fix.

No manual database or transcript edits were made during this reproduction or diagnosis. This report does not claim physical transcript deletion. The impact is loss of independently accessible history in the app, misleading old titles, and old session references resolving to an unrelated task.

Expected: New session must leave the old conversation independently accessible and must not silently replace the conversation behind an existing entry.

No private repository names, local user paths, real session/workspace IDs, prompt contents, credentials, raw transcripts, or database files are included here.

[bytetopia]

Same! This is so stupid and I can't even get back to an older version because it says data is created by a new version, and I must lose all session history if I want to go back. So stupid issue to appear in a prod release.