[0xping]

Problem

On a WSL-only desktop install, the Browser panel does nothing: you type a URL, press Enter, the address bar resets to "Search or enter URL", and no page loads. Agent preview_open/preview_navigate on the same environment work. Reported in #17009.

Change

This follows the first fix option in the maintainer's diagnosis on #17009 . A WSL primary is bootstrapped over stdin, so it never gets the desktop browser channel fds. Its server runs tabs on its own headless page, but the desktop still mounted a local serverDriven <webview> for them, because rendersServerTabNatively assumed every primary holds the channel. Typed URLs went to that webview, and the server never heard about them.

• contracts: new optional capability desktopBrowser.
• server: ServerEnvironment advertises it only when both desktopBrowserFd and desktopBrowserControlFd are set. This uses the same static-fd reasoning as desktopAppUpdate.
• web: rendersServerTabNatively also requires the primary's desktopBrowser. Without it, ElectronBrowserHost mounts no webview and PreviewView/ThreadPreviewMiniPlayer stream the tab, the same as for any other environment's server tabs.

Every native-vs-stream decision in the web client goes through rendersServerTabNatively, so this covers the panel, the mini player, and the host. Mobile always streams and is unchanged. The client and its primary server ship in one desktop artifact, so the primary never runs an older server without the key.

Scope and approval

This is a bug fix for triaged issue #17009. A maintainer traced it to this code path and proposed this direction ("the server could advertise a capability only when DesktopBrowserChannel.available, and rendersServerTabNatively could require it"). The change covers that one problem only.

Verification

• Reproduced on Windows 11 + WSL2 with T3 Code in WSL-only mode (0.0.46 nightly). On a new tab, typing example.com or https://x.com/home and pressing Enter left the tab with url: null. Results were the same with the Incognito profile, when typing the URL instead of pasting it, and after a full restart. preview_open/preview_navigate to the same URLs loaded fine in that environment, which matches the headless-page split described in the issue.
• Focused tests: vp test run apps/web/src/browser/previewRuntime.test.ts apps/server/src/environment/ServerEnvironment.test.ts gives 14/14 passing.
  • New server test: desktopBrowser is advertised with both channel fds and absent without them (the WSL primary case), while serverBrowser stays true.
  • New web test: the primary's server tabs render natively only with desktopBrowser. Remote environments and non-server tabs are unchanged.
• Typecheck: tsc --noEmit passes for @t3tools/contracts, @t3tools/web and t3. vp lint and vp fmt --check are clean on the changed files; the one lint warning in ElectronBrowserHost.tsx was already there before this change.
• Not checked: I couldn't build and run a patched Windows desktop app against a WSL-only primary, so the streamed tab after the fix is unverified in a real client. A maintainer with a WSL-only setup should confirm that typed navigation now loads and streams.

Model: Claude Opus 5.5 (claude-opus-5-5), harness: Claude Code in T3 Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at aa3b0b9

Macroscope's review found this PR approvable — This is a focused WSL browser bug fix that adds a backward-compatible capability flag and routes only primaries without the desktop browser channel through the existing server-streaming path. Native rendering remains unchanged when the channel is available, and focused server and web tests cover the decision logic.

^{You can add or adjust custom eligibility rules. Learn more.}