Open in IDE: vscode:// link broken when Archon runs in WSL2 and the browser is on Windows

[blankse]

Bug

The "Open in IDE" buttons emit a vscode://file/<absolute-path> link, where <absolute-path> is the path on the server (where Archon runs). When Archon runs inside WSL2 and the user opens the Archon Web UI from a Windows browser, the path is a Linux path like /home/datafactory/.archon/workspaces/.../source — but Windows VS Code receives vscode://file//home/datafactory/... and tries to resolve it on Windows. There is no /home/datafactory/ on Windows, so VS Code opens an empty / "file not found" window.

VS Code does support WSL paths via a different scheme:

vscode://vscode-remote/wsl+<distro>/<linux-absolute-path>

Archon needs to use that variant when running under WSL2.

Steps to Reproduce

1. Run archon serve inside a WSL2 distro (Ubuntu, Debian, …).
2. From the Windows host browser, open http://localhost:3000.
3. Click Open in IDE in the Header (or "Open in IDE" on a workflow run card).
4. VS Code launches but reports the path can't be opened — the Linux path was passed verbatim to Windows VS Code.

Expected vs Actual

• Expected: VS Code opens the workspace folder via the WSL remote, identical to running code . from inside the WSL shell.
• Actual: VS Code launches with an unresolvable path on Windows.

Affected code

Two call sites construct the vscode://file/... URI directly, with no platform handling:

• packages/web/src/components/layout/Header.tsx:32

  window.open(`vscode://file/${normalizedPath}`, '_blank');

• packages/web/src/components/dashboard/WorkflowRunCard.tsx:300

  href={`vscode://file/${run.working_path.replace(/\\/g, '/')}`}

Suggested Fix

1. Detect WSL on the server. Add an isWSL() helper in @archon/paths analogous to the existing isDocker(). WSL is detectable via:

   • process.env.WSL_DISTRO_NAME (set inside every WSL distro)
   • /proc/sys/kernel/osrelease containing microsoft (lower-cased)

2. Expose it through the existing health/info endpoint. GET /api/health already returns is_docker (packages/server/src/routes/api.ts:2682). Add is_wsl and wsl_distro (the value of WSL_DISTRO_NAME).

3. Adapt the link helpers. A small util like:

   function ideUri(path: string, env: { isWsl: boolean; wslDistro?: string }) {
     const p = path.replace(/\\/g, '/');
     return env.isWsl && env.wslDistro
       ? `vscode://vscode-remote/wsl+${env.wslDistro}${p.startsWith('/') ? p : `/${p}`}`
       : `vscode://file/${p}`;
   }

   Both Header.tsx and WorkflowRunCard.tsx then call this helper instead of building the URI inline.

4. Optional follow-up: same idea applies to remote SSH setups (vscode://vscode-remote/ssh-remote+<host>/<path>). Could later be generalized; WSL is the common case for now.

Impact

Affects every Windows + WSL2 dev who interacts with Archon via the Web UI. Workaround today is to copy the path with the existing copy-path button and wsl --cd <path> code . manually — friction every time.

Scope

• Packages: paths (env detection), server (health endpoint extension), web (URI construction)
• Breaking change: no
• Database changes: no

Definition of Done

• isWSL() helper added to @archon/paths, with tests covering env var and /proc/sys/kernel/osrelease detection
• /api/health reports is_wsl + wsl_distro
• Header.tsx and WorkflowRunCard.tsx build the WSL-flavoured vscode://vscode-remote/wsl+<distro>/... URI when the server reports is_wsl: true
• Smoke test from a WSL2 setup: Open in IDE opens VS Code with the correct workspace folder via the WSL remote

[Wirasm]

potentially related to PR #1504.