Update of #314122 reported on Augusted 13th, 2026

We have written the needed data into your clipboard because it was too large to send. Please paste.

The extension-host crashes have returned after the recent VS Code/Copilot update. This was reported by me on August 13th. #314122

Environment for this recurrence:

```text
VS Code: 1.137.0 Stable (Windows x64)
VS Code commit: 645f29cc3176500b4b5762ba887cf2a7f0ffdf2c
GitHub Copilot Chat: 0.65.0
Log session: 20260911T185207
```

The main log records **five local extension-host exits with code 134 in approximately four minutes**, across two VS Code windows:

```text
18:53:35 PID 1940 exited with code 134
18:54:51 PID 32480 exited with code 134
18:55:58 PID 11092 exited with code 134
18:56:16 PID 24536 exited with code 134
18:57:10 PID 17116 exited with code 134
```

The replacement hosts ran for only approximately **72–86 seconds** before aborting. VS Code automatically restarted each host until the repeated-failure condition was reached.

The two windows had different sets of optional extensions active, but both included `GitHub.copilot-chat` and the built-in Git/GitHub authentication extensions. The second window did not have OpenAI ChatGPT, C#, Python, Pylance, or the other third-party extensions from the first window, yet its extension host also exited with code 134. This narrows the common path considerably and is consistent with the earlier Copilot A/B comparison reported on this issue.

During this session, the Copilot log for one window repeatedly reported:

```text
Failed to create database. Falling back to in-memory db: Error: unable to open database file
```

The shared Copilot state database is located under:

```text
%APPDATA%\Code\User\globalStorage\github.copilot-chat
```

I checked the database read-only. `PRAGMA quick_check` returns `ok`, it is using WAL journal mode, and the directory/database ACL grants the current user Full Control. Therefore, this message does not look like simple SQLite corruption or a missing filesystem permission. Because two VS Code windows were using the shared Copilot state, a locking or lifecycle problem is possible, but I cannot establish that as the root cause. The second window also crashed without recording the database-open message, so it may be a symptom rather than the trigger.

This capture does **not** contain the earlier `TypeError: e is not iterable` / `setItems` stack. It does contain a separate JavaScript debug-adapter exception involving `_addSourceMapSources` and `lastIndexOf`, plus several missing/blocked source-map messages. Those appear to be debugger/source-map diagnostics and do not account for every host abort. The Node `url.parse()` and `Buffer()` deprecation warnings also appear non-fatal.

The strongest new evidence is therefore:

- The failure is reproducible on VS Code 1.137.0 with Copilot Chat 0.65.0.
- Five independent extension-host processes exited with code 134 in a tightly repeatable 72–86 second interval.
- It occurred in two windows with different optional extension sets but a common Copilot/GitHub path.
- Resetting/disabling Copilot remains the only reliable workaround; restarting Windows helps only temporarily.

I have preserved the complete log directory and can provide a newly redacted diagnostic archive if requested:

```text
%APPDATA%\Code\logs\20260911T185207