Extension Development Host window disappears immediately when debugging extensions on WSL remote

[eamodio]

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

Version: 1.115.0-insider (user setup)
Commit: 53fb310ae033b6fc8f6a3599a168028cb08ad37d
Date: 2026-04-07T09:41:08Z
Electron: 39.8.5
ElectronBuildId: 13703022
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26300

When launching a debug session that opens an Extension Development Host (EDH) window targeting a WSL (or SSH -- though SSH seems to be rare) remote, the EDH window frequently opens and then immediately closes. This happens multiple times in a row before eventually succeeding — the behavior is intermittent and depends on remote connection timing.

Steps to Reproduce

• Open VS Code and connect to a WSL remote
• Open an extension project
• Press F5 to launch the Extension Development Host
• The EDH window opens briefly, then closes
• Repeat — after several attempts it eventually stays open

Expected Behavior

The Extension Development Host window should open and remain open reliably, surviving transient connection hiccups during startup.

Analysis

Since I can't debug this as the Remote extensions are all closed source and locked to proper VS Code builds, I can only rely on what Claude's analysis says:

The issue is a race condition in the remote extension host startup handshake. When the EDH window connects to the remote extension host, there is a handshake phase where Ready and Initialized messages are exchanged. If the underlying socket experiences a transient close during this phase (common in WSL/SSH due to variable tunnel establishment and remote process startup timing), the onSocketClose handler in RemoteExtensionHost immediately triggers _onExtHostConnectionLost, which closes the debug session and the window.

This is in contrast to non-dev-host remote connections, where PersistentConnection handles socket closes with reconnection logic and exponential backoff. The extension dev host onSocketClose handler bypasses this reconnection entirely, treating every socket close — even during initial startup — as a terminal event.

Fix (Claude)

Again as the Remote extensions are closed source and locked to VS Code builds, I cannot verify this fix.

diff --git a/src/vs/workbench/services/extensions/common/remoteExtensionHost.ts b/src/vs/workbench/services/extensions/common/remoteExtensionHost.ts
index cc716aa469f..2e2fe4d4a19 100644
--- a/src/vs/workbench/services/extensions/common/remoteExtensionHost.ts
+++ b/src/vs/workbench/services/extensions/common/remoteExtensionHost.ts
@@ -137,12 +137,6 @@ export class RemoteExtensionHost extends Disposable implements IExtensionHost {
 					this._onExtHostConnectionLost(reconnectionToken);
 				});
 
-				protocol.onSocketClose(() => {
-					if (this._isExtensionDevHost) {
-						this._onExtHostConnectionLost(reconnectionToken);
-					}
-				});
-
 				// 1) wait for the incoming `ready` event and send the initialization data.
 				// 2) wait for the incoming `initialized` event.
 				return new Promise<IMessagePassingProtocol>((resolve, reject) => {
@@ -169,6 +163,17 @@ export class RemoteExtensionHost extends Disposable implements IExtensionHost {
 							// stop listening for messages here
 							disposable.dispose();
 
+							// Close the extension development host window when the
+							// socket closes after the handshake completes. During
+							// the handshake, PersistentConnection's reconnection
+							// logic handles transient socket drops (e.g. in WSL/SSH
+							// scenarios where remote startup timing is variable).
+							protocol.onSocketClose(() => {
+								if (this._isExtensionDevHost) {
+									this._onExtHostConnectionLost(reconnectionToken);
+								}
+							});
+
 							// release this promise
 							this._protocol = protocol;
 							resolve(protocol);

/cc @aeschli @roblourens

[eamodio]

@connor4312, I collected more data from WSL repros (it does seem to be WSL only).

I can reproduce it with:

• a fresh profile with no extensions
• a trivial extension, not just GitLens

I also captured good and bad runs back-to-back.

In the good run, the remote Extension Host socket connects and stays up until I manually close the session.

In the bad run, the renderer log shows the remote Extension Host websocket closing unexpectedly:

[remote-connection][ExtensionHost] received socket close event (wasClean: false, code: 1006, reason: )
[remote-connection][ExtensionHost] starting reconnecting loop
[remote-connection][ExtensionHost] starting reconnection with grace time: 10800000ms

Immediately after that, the local extension host log shows:

Extension host terminating: received terminate message from renderer

I also saw a separate failure mode in earlier WSL runs where the remote Extension Host dies right after debugger attach, including for a trivial extension:

Loading development extension at /home/eric/code/eamodio/vscode-simple
Debugger attached.
TypeError: Class extends value undefined is not a constructor or null
Assertion failed: Cannot toggle network tracking, please report this.
Extension Host Process exited with code: null, signal: SIGABRT.

Hope that pin it down — this is driving me nuts as I sometimes have to start/restart the debugger 3-6 times before it stops disappearing