Agent mode: sending message mid-response sometimes forks session into two parallel agents, causing conflicting edits and JSONL corruption

[puigru]

• Copilot Chat Extension Version: 0.37.8
• VS Code Version: 1.109.5 (0725862, x64)
• OS Version: LMDE 6 (faye), Linux 6.1.0-43-amd64 x86_64
• Feature: Agent mode
• Selected model: Claude Opus 4.6
• Logs: N/A (session file evidence attached)

---

Bug summary

Sending a new message while the agent is mid-response sometimes causes the session to bifurcate into two independent agent threads running simultaneously. When it triggers, both agents continue operating on the project in parallel, each with their own "mind", starting from the point in the conversation where the new message was sent. This is likely a race condition — it doesn't happen every time, but when it does, it leads to:

1. Conflicting file edits — two agents editing the same codebase at once with no coordination
2. Session file corruption — both threads write to the same .jsonl session file concurrently, interleaving JSON entries inside each other's data

Steps to reproduce

1. Start an agent mode session with a complex multi-step task
2. While the agent is mid-response (actively running tools, editing files), send a new message to redirect/steer it
3. Sometimes (likely depending on timing — what stage the agent's response is in when the new message arrives), instead of the first response being cancelled, both the old and new response threads continue running simultaneously
4. Observe two parallel streams of tool calls and file edits happening at once
5. Close VS Code to stop the chaos
6. The session file is now corrupted: ChatSessionStore: Malformed session data in .../chatSessions/<id>.json

Note: This doesn't happen every time a message is sent mid-response. It appears to be a race condition — the cancellation of the previous response and the start of the new one are not properly serialized, so depending on timing, the old response may escape cancellation and keep running alongside the new one.

Expected behavior

Sending a new message while the agent is responding should always cancel the in-progress response before starting the new one. Only one agent thread should ever be active at a time within a session.

Actual behavior

The previous response is sometimes not cancelled. A second response thread is spawned while the first is still running. Both run simultaneously, making independent tool calls and file edits. The session effectively "splits in two."

Evidence from the corrupted .jsonl file

Line 137 of the session file had two JSON entries merged into one line — a {"kind":1,...} entry was written inside a string value of a {"kind":2,...} entry:

{"kind":2,"k":["requests",8,"response"],"v":[...,"value":"...post-build.sh 2>\n/dev/null\n{"kind":1,"k":["hasPendingEdits"],"v":false}

This proves two writers were appending to the file concurrently without any mutual exclusion.

Impact

• High / potentially destructive — two uncoordinated agents making conflicting edits to a real project can introduce bugs, overwrite each other's changes, or corrupt source files
• Session becomes permanently unloadable after the interleaved writes
• The only way to stop it is to force-close VS Code
• Required manual JSON surgery to repair the session file

Suggested fixes

1. Ensure cancellation of the in-progress response is awaited/completed before starting a new one — the race condition suggests cancellation is fire-and-forget, allowing the old response to continue if the cancel doesn't land in time
2. Enforce single-writer semantics on session .jsonl files (lock or queue)
3. Add integrity validation on write (detect multiple JSON objects on one line)
4. Add auto-recovery for simple corruption patterns (split merged lines)