[Bug]: Open in editor is hidden for threads in the WSL environment when Windows is the primary#25427

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. On the Windows desktop app, open Settings → Connections, set WSL backend to a distro (Ubuntu here), and leave WSL only off, so the Windows and WSL backends both run.
2. Add a project in the WSL environment and start a thread there, for example in a new worktree.
3. Open the thread details panel (Ctrl+Shift+B) or press Ctrl+O.

Expected behavior

The panel shows Open in <editor> and Ctrl+O opens the thread's folder or worktree in the editor, the same as for threads in the Windows environment.

Actual behavior

The thread details panel has no editor control, and Ctrl+O does nothing. There is no way to open a WSL project or worktree in an editor from T3 Code in dual mode. I had to find the worktree path (~/.t3/worktrees/<repo>/<id> inside the distro) and run code on it by hand.

shouldShowOpenInPicker in apps/web/src/components/chat/OpenInPicker.logic.ts shows the picker for the primary environment, and otherwise only when remoteOpenMode !== "local-exec". resolveRemoteOpenState in apps/web/src/remoteOpen.ts returns LOCAL_EXEC for a desktop-local target (isDesktopLocalConnectionTarget), which is what the WSL environment is in dual mode. So no branch shows the picker for WSL threads, and useOpenFavoriteEditorShortcut is disabled by the same flag.

History

• #2361 limited the picker to the primary environment. Non-primary then meant remote machines, where the primary server's editor list doesn't apply.
• #6572 added SSH deep links for remote environments and kept WSL hidden on purpose, with the comment: "Non-primary local backends (e.g. WSL) keep it hidden, matching pre-remote behavior." The test hides the picker for non-primary local backends encodes this. The comment was later removed in #19559.
• #9426 and #14571 showed the picker for the WSL backend and opened the editor from the Windows host through <scheme>://vscode-remote/wsl+<distro>/<path>, using the host's editor list. They also found that the desktop's external URL allowlist (ElectronShell.ts) only passes ssh-remote+ links. #15164 proposed a "Local WSL" setting instead. All three were closed for evidence or size. Closing #14571 and #15164, a maintainer asked to "preserve the broken WSL editor flow in an issue" and agree on a much smaller fix. I couldn't find that issue, so this is it.
• Related: Ideas discussion #18515 covers the same "local but not primary" gap for saved environments on the same machine, such as the background service at 127.0.0.1. It doesn't cover WSL.

Impact

Minor bug or occasional failure

Version or commit

0.1.2 (Windows desktop); logic unchanged on main @ 242d00cd34

Environment

Windows 11 Pro 26200, WSL Ubuntu 24.04.3 (x86_64), VS Code 1.141.0 with the WSL extension. code resolves inside the distro through Windows PATH interop.

Workaround

Open the folder by hand: code <path> from the distro, or code --remote wsl+Ubuntu <path> from Windows.