Extension host restarts on every chat turn after an in-place update, silently resetting Copilot Chat session state (model, agent, MCP servers)

## Does this issue occur when all extensions are disabled?

Not verified — the issue is in Copilot Chat session state, so disabling all extensions removes the observable surface. I can retest with a minimal extension set on request.

## Version

- VS Code (running processes): **1.126.0**
- VS Code (staged on disk during the session): **1.134.0**
- GitHub Copilot Chat: **0.54.0**
- OS: **Windows 11 x64**, user-scope (non-admin) install

## Steps to Reproduce

1. Run VS Code for an extended period (my processes had been up for ~9 days).
2. Let the auto-updater download and stage a newer build in the background. In my case it wrote a new versioned build directory and ran the installer with `/nocloseapplications`, i.e. it did **not** require the running instance to exit.
3. Without restarting, continue using a Copilot Chat agent session that has non-default settings — a specific model, a specific reasoning effort, a custom agent, and MCP servers enabled.
4. Send several messages over the course of ~20 minutes.

## Actual Behavior

The chat session is torn down and re-created on **every turn**. Consequences, all user-visible but none surfaced as an error:

1. **Session settings silently revert to defaults each turn.** I selected a specific model at *high* reasoning effort and got *medium*. My selected custom agent was not applied — it was offered only as a delegatable subagent.
2. **MCP servers turn themselves off.** Re-enabling them between turns did not stick. `stdio`-based servers are child processes of the extension host, so each restart kills them; no MCP server processes were alive when I checked.
3. **MCP tools disappear mid-turn.** In one turn a tool call against an MCP server succeeded; a few minutes later, within the same conversation, the same tool no longer existed in the tool list. The failure mode was `No MCP client found for tool ID: `, then on retry `Tool '' does not exist`.
4. **Previously rendered output is lost** when switching between chat sessions and back, because the session is re-created rather than restored.
5. **Nothing tells the user any of this is happening.** No notification, no "reload required" prompt, no error. The model appears to ignore instructions and behave erratically, so the natural conclusion is that the *model* or the *user's configuration* is broken. I spent a full troubleshooting cycle chasing a non-existent MCP configuration problem before finding the real cause.

## Expected Behavior

- If an update is staged that leaves the running extension host inconsistent, **prompt the user to restart** (as VS Code already does for extension updates) instead of degrading silently.
- Chat session settings — model, reasoning effort, selected agent, MCP enablement — should either **survive** an extension host restart, or the user should be **told** they were reset.
- If MCP servers die because their host restarted, surface that as a **visible, actionable error** rather than silently removing tools from the model's tool list mid-conversation.

## Diagnostic Evidence

The Copilot Chat debug log for the affected session contains **five `session_start` events and nothing else** — no model requests, no tool calls, no customization-loading events. The timestamps match my five messages to within ~2 seconds each:

| session_start | user message |
|---|---|
| 13:57:47 | 13:57:49 |
| 14:00:49 | 14:00:49 |
| 14:05:57 | 14:05:59 |
| 14:10:15 | 14:10:17 |
| 14:19:53 | 14:19:55 |

I checked four separate sessions in this workspace: **all** contain only `session_start` events. So conversation-level diagnostic logging captured nothing at all, which made this substantially harder to diagnose than it should have been. That looks like a second, independent bug — the logging paths appear not to match the swapped-out build.

Supporting observations at the OS level:

- 11 VS Code processes running, all started 9 days before the session, reporting **1.126.0**.
- A build directory for **1.134.0** created *during* the session (~2h before the failures started).
- The installer process still alive ~2h20m later, launched with `/nocloseapplications`.
- **Seven** versioned build directories accumulated in the install folder. Notably, the running extension host was loading some of its bundled assets from a build directory dated **~2 months earlier** than the newest one — so more than one version mismatch was in play simultaneously.
- No MCP server processes alive, despite MCP being configured and having worked earlier in the session.

## Additional Context

A full restart of VS Code is the obvious workaround, but the user has no way to know that's what's needed. Every symptom points at the AI or at the user's own configuration:

- the model "downgrading" itself,
- a custom agent being "ignored",
- MCP toggles that "won't stay on",
- tools that exist in one message and not the next.

The underlying cause — a background update that left the running instance inconsistent — is completely invisible from the chat UI. Even a generic "VS Code was updated in the background; reload to restore full functionality" notification would have prevented the entire investigation.