Workspace folder content was deleted while VS Code was running (Remote-SSH + Agent Host) — need help identifying whether any VS Code component did it

Does this issue occur when all extensions are disabled?: No

Note on the answer above: the event is a one-off data-loss incident and is **not reproducible on
demand**, so extension bisect cannot be applied retroactively. I am not claiming VS Code is the
cause; the actor is undetermined. I am filing this to ask for guidance on which VS Code component
(if any) could delete a workspace folder recursively, and which diagnostics would prove or exclude
each component.

- VS Code Version: 1.137.0, server commit 645f29cc3176500b4b5762ba887cf2a7f0ffdf2c (Remote-SSH; client = macOS, remote = Linux)
- OS Version: Remote: Ubuntu 20.04.6 LTS, kernel 5.15.0-139-generic, root filesystem XFS (/dev/nvme0n1p2).
Client: macOS (VS Code 1.137.0). Window log dirs on the remote:
`~/.vscode-server/data/logs/20260913T134231` and `.../20260913T134232` (agent host + AHP logs)

Steps to Reproduce:

1. Open a workspace folder over Remote-SSH (`/home/lion/works/agent-app`) in a window whose
integrated terminal runs a long external process — in my case a ~33-minute test suite
(`fibjs test/all.test.ts`, PID 474555, started 14:06:51 UTC) that spawns many child processes
(http servers, mocks, docker CLI, and a third-party sandbox CLI).
2. Wait while that command is still running (~31 minutes in).

Expected: workspace contents are untouched by VS Code.

Actual: at 14:37:46 UTC the **entire workspace folder was emptied** — all files and subdirectories
including `.git`, nothing recoverable:

- `14:31` folder still intact (an app process was still writing under it).
- `14:37:43` `~/.vscode-server/data/User/workspaceStorage//` mtime updated and the Copilot
codebase index DB (`codebase-external.sqlite`) went to 0 rows — i.e. VS Code components were
*reacting to* files already gone, ~3 s before the folder mtime.
- `14:37:46` `/home/lion/works/agent-app` mtime changed; afterwards it contains only an empty
`temp/` folder (new inode). Sibling folders were unaffected.
- Processes that had the folder as cwd (`bash`, extension-host, forked app processes) now show
`/home/lion/works/agent-app (deleted)` with an empty directory, so open file handles could not
recover anything.
- `14:39:33` tool calls that read files under it fail with
`cannot open vscode-remote://ssh-remote+pc/home/lion/works/agent-app/... (Unable to resolve nonexistent file)`.

Investigation already done on the VS Code side (no findings, details available on request):

- Extension host logs (`logs/20260913T134231/exthost*/**/*.log`): no delete/unlink/recurse operations.
- `ptyhost.log`: no task or terminal launch by VS Code in that window on that day.
- Agent Host log (`agenthost.log`) and AHP protocol logs (`ahp/*.jsonl`): only initialize and
`root/configChanged` actions; no terminal command payloads.
- Session transcripts of all workspaces under this server: only one chat session was active today.
- `agent-host-config.json`: no sandbox runtime configured, `permissions.allow/deny` empty.
- The integrated terminal used is **not** sandboxed: process ancestry is `bash <- MainThread <- code server`
and it shares the mount namespace with PID 1; no bwrap/boxsh wrapper in the chain.
- Extensions installed on the remote: ms-azuretools.vscode-containers, ms-vscode.cmake-tools,
ms-vscode.cpptools (+pack/themes), smallmain.vscode-unify-chat-provider,
xicilion.markdown-viewer-extension.

Other actors we are still investigating (listed for completeness, not as a VS Code claim): the
deletion overlaps exactly with the phase of the test suite that drives a third-party sandboxing CLI
which had been rebuilt/reinstalled on that machine 6 minutes before the run; that tool is the
current leading hypothesis.

Questions / asks:

1. Is there any VS Code component (file watcher, codebase indexer, chat-editing checkpoints, git
integration, agent host, task runner) that can remove an entire workspace folder, including
`.git`, without leaving any log line?
2. Which additional logging (e.g. verbose file-watcher/deletion tracing, or the code path that
produces "Unable to resolve nonexistent file") should we enable to identify the actor?
3. If VS Code can be ruled out by design, please say so and I will close this and report elsewhere.
I will update this issue once I have a reproduction (planned: run the same suite from a plain
terminal, i.e. without VS Code, against a copy of the folder with canary files).