Dev Containers: extension host flagged unresponsive + 1006 tunnel drops under heavy git/file-watch load, disposing remote webviews

Summary

In a Dev Container, heavy filesystem activity — e.g. git checkout across several repositories at once — intermittently causes the remote extension host to be flagged unresponsive, the management / extension-host tunnel to drop with WebSocket code 1006 (abnormal closure), and remote-bound webviews to be disposed and recreated. The connection self-heals in ~100–200 ms and the extension host process never crashes (same pid throughout), but the brief stall is enough to tear down and reset webviews (and any extension state held in them).

Environment

• VS Code (stable), Dev Containers (Remote - Containers)
• Container: Linux, arm64, on Docker Desktop (linuxkit VM); host appears to be Apple Silicon macOS
• Workspace contains several independent git repositories under a common parent directory

What the logs show (server side, inside the container)

• remoteagent.log: repeated paired reconnects — [ManagementConnection] The client has reconnected. / [ExtensionHostConnection] The client has reconnected. — recurring throughout the day, for days.
• At the disruptive event: multiple CodeExpectedError: Could not find pty N on pty host, and a file-watcher error: [File Watcher ('parcel')] Unexpected error stopping watcher: Unable to remove watcher: Invalid argument (path: …).
• remoteexthost.log: the extension host keeps the same pid across the event; no exception is logged.
• Client side (renderer.log on the host): every socket close … code: 1006 is followed by reconnected! within ~100–200 ms; the renderer never crashes. The client also flips the remote extension host between "unresponsive" and "responsive" repeatedly during these periods.

Steps to reproduce (not yet minimal)

1. Open a workspace containing several git repositories in a Dev Container (Docker Desktop, macOS host).
2. With extensions that hold webview state active, trigger a large burst of file changes — e.g. git checkout <branch> across several repositories simultaneously.
3. Observe the extension host being flagged unresponsive, a 1006 tunnel drop/reconnect, and remote-bound webviews being disposed/recreated.

Expected

A sub-second tunnel reconnect should not require disposing webviews; or, if disposal is unavoidable, it should be coordinated so extensions can serialize/restore their state.

Notes / open questions

• Unclear whether the trigger is the file watcher (the parcel "Unable to remove watcher: Invalid argument" error suggests watcher churn under the file storm), the heartbeat timing that declares the host unresponsive, or the Docker Desktop port-forwarding/proxy layer carrying the tunnel. Guidance on isolating this would be welcome.
• This may be partly environment-specific (Docker Desktop networking on macOS). Filing because the pattern is reproducible and the "unresponsive → webview disposal" behavior looks like something VS Code could make more resilient.
• Possibly related: #1257, and closed #10955 / #7999.