Windows 11 Explorer context menu "Open with Code" silently fails on `\\wsl.localhost\` (WSL) paths — Code.exe launched from the packaged verb runs inside an AppX container

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

### Environment

- VS Code: **1.136.1** (desktop / Inno Setup install, non-default location, with the sparse package `Microsoft.VisualStudioCode_1.0.136.1_neutral__8wekyb3d8bbwe` registered for
the Win11 top-level context menu)
- OS: Windows 11 25H2 (build 26200)
- WSL: 2.7.10, distro Ubuntu-24.04 (WSL2)
- Extensions: ms-vscode-remote.remote-wsl 0.104.3
- Settings: `security.allowedUNCHosts` contains `wsl.localhost` and `wsl$`

### Summary

The top-level Windows 11 Explorer context-menu entry **"Open with Code" does nothing** when invoked on folders under `\\wsl.localhost\\...`. No window, no dialog, no
error, no log output, no crash dump. The entry works normally on regular drive paths (`C:\...`). The same UNC path opens correctly when passed through the CLI.

### Repro steps

1. Windows 11 + WSL2 (any distro) + VS Code desktop with the Win11 context-menu integration + Remote - WSL extension installed.
2. In Explorer, open a folder under `\\wsl.localhost\\home\` (e.g., via the "Linux" node in the navigation pane).
3. Right-click the folder background and click **"Open with Code"** in the top-level (Win11) context menu.
4. Nothing happens.

### Controls (same machine, same path, same session)

| Action | Result |
|---|---|
| Right-click → "Open with Code" on a `C:\` folder | ✅ opens normally |
| `& "C:\\bin\code.cmd" --verbose "\\wsl.localhost\\home\"` in PowerShell | ✅ opens normally |
| `code .` inside WSL | ✅ opens as WSL remote window |
| Right-click → "Open with Code" on `\\wsl.localhost\...` (with or without `security.allowedUNCHosts` set) | ❌ silent failure |

### Evidence

**1. The packaged verb launches Code.exe inside the VS Code package's desktop AppX container**

Each context-menu click produces a container lifecycle in `Applications and Services Logs → Microsoft → Windows → AppModel-Runtime → Admin` (translated from localized log):

```
20:26:49 [210] Desktop AppX container {GUID} for package
Microsoft.VisualStudioCode_1.0.136.1_neutral__8wekyb3d8bbwe created
20:26:49 [211] Process added to desktop AppX container {GUID} for package
Microsoft.VisualStudioCode_...
20:27:02 [217] Desktop AppX container {GUID} destroyed
```

The containerized `Code.exe` lives 6–28 seconds and exits without ever creating a window. Seven such invocations were recorded during testing; **all failed identically** —
regardless of whether another VS Code instance was running.

The working CLI launch at the same time produced **no** container events (it runs outside the package container).

**2. The failing processes leave no logs at all**

The failed launches never created `%APPDATA%\Code\logs\` session directories (only an empty directory in the rare case where an existing instance put the new process
into relay mode). Nothing in Windows Error Reporting, nothing in `%LOCALAPPDATA%\CrashDumps`. This suggests the process dies before the logging service initializes.

**3. The same UNC path works fine outside the container**

Verbose log from the successful CLI launch of the exact same path:

```
[main ...] windowsManager#open pathsToOpen [
{ workspace: { id: '', uri: [Yo] }, type: 2, exists: true }
]
[main ...] window#load: attempt to load window (id: 1)
```

The window opened the UNC folder as a local workspace and ran normally. So the path itself, the UNC host allowlist (`security.allowedUNCHosts`), and the extension host are all
fine — the failure is specific to the packaged launch path.

**4. The context-menu verb is declared via the sparse package**

```xml















```

### Analysis

`code_explorer_command_x64.dll` (IExplorerCommand) is hosted in a packaged COM surrogate, and the `Code.exe` process it spawns inherits the package identity / desktop AppX
container. Inside that container, `\\wsl.localhost\...` (WSL's 9P-based file share) is not accessible, so validation of the CLI-argument path fails and the argument is dropped
silently (the CLI arg flow uses `ignoreFileNotFound` and filters unresolvable paths without showing a dialog). The process then exits.

Additionally, the UNC host allowlist is applied during full app startup in `main.js`:

```js
F && (this.configurationService.getValue("security.restrictUNCAccess") === !1
? r1()
: yo(this.configurationService.getValue("security.allowedUNCHosts")))
```

so `security.allowedUNCHosts` cannot help this launch path even when configured correctly.

Possibly the same happens for any UNC network share, not just `\\wsl.localhost` (not tested here).

### Expected behavior

At minimum the context menu should not fail silently. Ideally it should either:

- launch `Code.exe` outside the AppX container (so the path resolves and the existing allow-host dialog flow works), or
- convert `\\wsl.localhost\\...` / `\\wsl$\...` paths into a WSL remote window when the Remote - WSL extension is installed, or
- show the existing "host was not found in the list of allowed hosts" dialog like the CLI/full-startup path does.

### Workaround

A classic (non-packaged) registry verb bypasses the container and works, e.g.:

```reg
[HKEY_CURRENT_USER\Software\Classes\Directory\Background\shell\OpenWithCodeWSL\command]
@="wsl.exe -d --cd \"%V\" -- bash -lc \"code .\""
```

(Note: `bash -lc` is required — `~/.local/bin` is not on PATH in the default shell environment used by an Explorer-launched `wsl.exe`; a bare `-- code .` fails with "command not
found".)