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)
- Open a workspace containing several git repositories in a Dev Container (Docker Desktop, macOS host).
- With extensions that hold webview state active, trigger a large burst of file changes — e.g.
git checkout <branch> across several repositories simultaneously.
- 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
Summary
In a Dev Container, heavy filesystem activity — e.g.
git checkoutacross 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
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.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.renderer.logon the host): everysocket close … code: 1006is followed byreconnected!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)
git checkout <branch>across several repositories simultaneously.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
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.