[BUG] Local preview on Windows + WSL — five tools, five failures, for "show me my page"

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment

• Windows 11 Pro (build 26200)
• Claude Code, Opus 4.8 — (CLI version: fill in from About//status)
• Project in WSL2 (Ubuntu), opened over \\wsl.localhost\ubuntu\...
• SvelteKit + Vite dev server running inside WSL on :5173, exposed to Windows via wslrelay.exe
• node v25.5.0, npm 11.8.0

The whole ask: see my own page render to eyeball a CSS change. Should be zero-friction. Instead it burned a chunk of a session and never worked.

Five separate walls:

1. Preview won't use a server that's already running. preview_start sees my dev server on :5173 and bails — "Port 5173 is in use by wslrelay.exe … not a preview server." Working server, right there, and it refuses. "Attach to localhost:5173" should be the easy case, not an error.

1. When it tries to start the server itself, it can't — because WSL. Windows node gets a \\wsl.localhost\... UNC path as its working directory. Windows processes can't do that, so node falls back to C:\Windows and dies: Cannot find module 'C:\Windows\node_modules\.bin\vite'. If the project's on WSL, run the command in WSL (wsl.exe -e …). Solved problem everywhere else.

1. The Chrome extension can't stay connected for two calls in a row. "Not connected" ~4 times before it connected, worked for exactly two calls, then dropped again for 3 more retries. A preview flow needs several navigations — unusable if the socket dies every other call.

1. The privacy filter blocked reading my own page's DOM. document.body.innerHTML on my own localhost page → [BLOCKED: Cookie/query string data], because Vite module URLs carry ?v= query strings. Reading a local dev server I control is not exfiltration — and it kills the browser tools for the exact debugging they're for.

1. The debugger gets parked and the page serves blank. The inspector attached to the dev server ends up halted, so the browser's module requests never get served and the page renders as an empty ~495-byte shell — no <h1>, no content, blank title. Nothing to preview even once everything else connects.

Repro:

1. SvelteKit/Vite project in WSL2, opened in Claude Code on Windows over \\wsl.localhost\....
2. npm run dev inside WSL (server on :5173).
3. Ask Claude to preview/screenshot the page.
4. Watch all five fire.

Any one of these unblocks it:

• Let preview attach to an existing URL/port instead of insisting on owning the process.
• Detect WSL projects and spawn commands through wsl.exe, not Windows node with a UNC cwd.
• Make the Chrome extension bridge persist across calls.
• Stop tripping the privacy filter on query strings for localhost DOM reads.
• Don't leave the inspector parked so the app actually serves and renders.

Impact: On Windows + WSL — Microsoft's recommended dev setup — there is currently no working path for Claude to preview a local web app. It shouldn't take five tools and a dead end to render one page.

What Should Happen?

I ask Claude to preview my local app, and it shows me the rendered page. That's the entire expectation. Concretely:

• Attach to the server I already have. My Vite dev server is running on localhost:5173 (via the WSL relay). Preview should just connect to it — an existing URL/port is the easy case, not a "not a preview server" error.
• If it does launch the server, launch it correctly for WSL. When the project lives in WSL, spawned commands should run inside WSL (wsl.exe -e …), not as a Windows node process handed a \\wsl.localhost\... UNC working directory it can't use.
• The browser connection stays up for the whole task. One connect, then navigate → read → screenshot across multiple calls without the extension dropping to "not connected" mid-flow.
• Reading my own localhost DOM just works. document.body.innerHTML on a page I control shouldn't be blocked as "cookie/query string data" because a module URL has a ?v= on it.
• The page renders fully. The dev server serves its JS modules and the app mounts — a real <h1>, real content, real title — not a blank ~495-byte shell.

Net: on Windows + WSL, "show me my page" should be a one-shot, not five tools and a dead end.

Error Messages/Logs

Steps to Reproduce

1. SvelteKit/Vite project in WSL2, opened in Claude Code on Windows over \\wsl.localhost\....
2. npm run dev inside WSL (server on :5173).
3. Ask Claude to preview/screenshot the page.
4. Watch all five fire.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.197

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

_No response_