Existing session opens a different conversation while original agent remains active and inaccessible

Summary

A long-running Harness results and report session became associated with a different conversation about a 25-case fixture. The original reporting conversation remained on disk and was still executing, but looking up its original conversation ID or project-session handle returned the newer conversation instead.

This blocked access to active work and made cross-session messages unsafe: an exact old-session target could resolve to an unrelated conversation.

Environment

• GitHub Copilot app for Windows: 1.1.15.
• Embedded Copilot CLI: 1.0.83-5.
• Windows: 10.0.26200.
• Existing branch-backed workspace.
• Incident: 2026-09-08, approximately 14:41-15:09 PDT (UTC-07:00).

Session identities

Observed sequence

1. The original session was working on a report correction, with subagents reviewing and fixing implementation changes.
2. The newer conversation's session.start timestamp is 14:41:29 PDT. Its first user request concerns a separate intermediate-size fixture investigation.
3. At approximately 14:58 PDT, the user noticed the reporting session had changed to a different conversation.
4. list_sessions_and_chats returned Harness results and report with the newer conversation ID while retaining the same workspace, branch, and project-session creation time.
5. get_session(project_session_id="6fab97c9-5445-4c2d-8461-a49d2f82ad4b") returned ID b99c3d18-70b1-4e9b-bc33-946a2605721e.
6. Looking up project-session handle 485971f8-2510-400a-b7d8-e56b905139ae also returned the newer ID. Navigation using the original conversation ID did not restore the original history.
7. The original conversation was not deleted: its separate event history remained present and continued recording assistant/tool events through 15:00:59 PDT. The associated Copilot process was alive.
8. Later, the visible app entry was named New cases. The original conversation's local metadata name was H1 parser repairs, following subagent rename activity. These are observations, not an established cause of the conversation switch.

Expected behavior

• A running conversation remains accessible by its stable ID.
• A different conversation must not silently replace the original behind its existing identity.
• If multiple conversations share a workspace, users need a reliable conversation selector and a supported way to reopen earlier running conversations.
• Navigation and message delivery must distinguish an exact conversation ID from a workspace's current conversation rather than silently retargeting it.

Actual behavior and impact

The old conversation's ID resolves to a different conversation. Its history and running work still exist, but the user cannot reopen or supervise them through available navigation. The supervising session disabled automation to avoid sending report instructions into the unrelated conversation.

Recovery attempted

• App session listing and lookups using both original identifiers.
• Direct navigation to the original conversation.
• Inspection of the affected app entry, its session-information menu, and session search.
• Read-only confirmation of separate local histories and original-agent activity.

No agent was restarted or terminated, no duplicate resume process was launched, and no app database/history was edited or deleted as a recovery attempt.

Unknowns and requested investigation

The exact trigger is not established; these are incident observations, not deterministic reproduction steps. Please inspect the project-session/conversation association around 21:41-22:01 UTC using the IDs above, and provide a safe way to restore the original running conversation without interrupting either history.

Private source code, prompts, raw command lines, credentials, and complete logs are intentionally omitted.

Start with the session listing and lookup entry points named in the report: list_sessions_and_chats, get_session, and session.start, using the supplied conversation and project-session IDs around 21:41-22:01 UTC. Compare the separate event histories and returned identifiers; done means exact IDs no longer resolve to another conversation and both running histories can be reopened and safely supervised.