Archiving a chat session silently reverts workspace files to that session's stored snapshots

## Summary

Archiving one or more Copilot chat sessions appears to write those sessions' stored file
snapshots over the **current** contents of the workspace, silently reverting files to the state
they were in when the archived chat was active.

There is no prompt, no notification, no entry in the Timeline, and no undo. The files are
simply different on disk. Because the reverted content is internally coherent (it is a real
former state of each file), it does not look like corruption — it looks like uncommitted work
that someone else deleted.

Any file **not tracked by git**, or any work **not yet committed**, is unrecoverable.

## Impact

This is a silent data-loss bug triggered by a routine, apparently read-only UI action.

Two occurrences on this machine, a month apart:

| Date | Chats archived | Files overwritten | Lines lost |
|---|---|---|---|
| 2026-07-21 | 1 | 9 | ~579 |
| 2026-08-18 | 6 | 16 | ~5,400 |

In the second incident the overwritten set included application source, test files, and
project documentation. One source file lost an entire feature's dependency-injection
registration — the solution still **compiled cleanly**, because unmapped endpoints and
unregistered services compile fine and simply do not exist at runtime. The loss was not
discovered by the build. It was discovered by a test that reads source files from disk.

The severity is amplified by the failure mode being invisible:

- The build stays green.
- The diff "looks like" ordinary uncommitted work.
- The reverted content is byte-identical to a real earlier commit, so nothing appears mangled.

## Steps to reproduce

I have **not** reproduced this on demand — see *Confidence* below. The observed sequence was:

1. Work in a workspace across several Copilot chat sessions over days or weeks, with those
sessions editing files.
2. Later, in a new session, make changes to some of those same files and **do not commit**.
3. Open the chat history and use the **Archive** action on one or more older sessions.
4. Inspect the workspace.

**Expected:** archiving is a history-management action. It should not touch the working tree.

**Actual:** files touched by the archived session(s) are rewritten with content from those
sessions, in a burst, within seconds of the archive action.

## Evidence

The correlation is between file modification times in `.../workspaceStorage//chatSessions/`
and the modification times of the affected workspace files.

### 2026-08-18 — six sessions archived

Six session files rewritten:

```
18:02:31 c7ec3add-6c70-450e-a725-11f0446fb6fc.jsonl
18:02:34 a5cde24e-b22b-450d-a613-0361d7596846.jsonl
18:02:54 84dc7433-cd34-4237-a137-9fdd12380595.jsonl
18:02:54 8c1c6bd2-e6fc-458f-8c41-a2cdd7f691eb.jsonl
18:02:56 f3d3ac80-59d8-497d-9655-1cfd721a78f1.jsonl
18:03:05 dfb5f540-7a04-4ac8-a099-d2fe9c5cf5e6.jsonl
```

Sixteen workspace files were rewritten between **18:02:40 and 18:02:55** — inside that window.
Grouping the affected files by modification time to the minute shows all sixteen in a single
minute, whereas genuine editing activity that afternoon shows one to five files per minute
spread across the preceding hours.

**Six chats archived; exactly six session files touched.**

### 2026-07-21 — one session archived

```
11:26:27 5043e67f-569f-43a8-b938-19d0f0712b62.jsonl
```

Nine workspace files were rewritten at **11:25:51**. Each was verified with `git hash-object`
to be byte-identical to that file's content in a commit from roughly a week earlier.

### Mechanism (inferred)

`workspaceStorage//chatEditingSessions/` contains content-addressed blobs named like
short hashes, alongside `state.json`. These appear to be the file snapshots backing
undo / accept / reject of AI edits. The symptoms are consistent with the archive path
writing a session's stored snapshots back to disk:

- **Burst write** — sixteen files in one minute is programmatic, not typing.
- **Coherent old content** — the files land on real former states, byte-identical to earlier
commits, which is what a snapshot store would contain.
- **Scoped to the session** — only files that the archived sessions had touched were affected.

## Confidence, stated honestly

What is established: two independent incidents a month apart, each with chat-session store
writes tightly coupled in time to a burst overwrite of workspace files, and a matching count
(six archives, six session files) in the second.

What is **not** established: I have not reproduced this deliberately, and I cannot rule out a
confounding action taken at the same moment. The ordering also differs slightly between the two
incidents — in 2026-08-18 the session writes bracket the file writes; in 2026-07-21 the session
write follows the file writes by 36 seconds.

The chat session `.jsonl` files and the workspace storage for these dates still exist on this
machine and can be supplied if useful.

## Not a duplicate of

- **#265794** — *Copilot Agent applies superseded edits from conversation history, corrupting
file state.* Same subsystem family (`chat-agent-editing`) and closed as fixed in 1.107. That
issue concerns **Keep Changes** replaying composite diffs during an **active** session. This
one is triggered by a UI action on an **inactive, archived** session, with no agent running
and no pending edits, on 1.134.0.
- **#321290** — *Chat session marked empty and hidden while Copilot transcript/edit state remain
intact.* Concerns session/edit-state divergence, but no workspace file modification.
- **#287224** — *Lost DAYS of work.* Unrelated; an agent executed `rm -rf`.

## Suggested handling

Whatever the eventual root cause, two things would have prevented the loss:

1. **Archiving should never write to the working tree.** If restoring snapshot state is
genuinely intended, it should require explicit confirmation naming the files.
2. **Any programmatic overwrite of workspace files should be undoable** — a Timeline entry or
a local-history snapshot taken *before* the write.

## Environment

```
Copilot Chat Extension Version: 0.62.0
VS Code Version: 1.134.0 (stable)
OS Version: Windows 11 25H2
Feature: Squad/Agent
Selected model: Claude Opus 5
Commit: 110a328ea54b42367b803ec53ee0bf52ef26b419
Workspace: single-folder, git-tracked
```

## Workaround

Commit before archiving chat sessions. Archiving against a clean working tree is harmless —
everything lost in both incidents was uncommitted.

A useful detection signature, if others suspect they have hit this: group changed files by
modification time to the minute. Ten or more files written in a single minute, whose diff
only *removes* recent work, is this failure rather than an ordinary uncommitted change.