Skip to content

bug: shouldLaunchBrowser() returns true on WSL2 because WSLg sets DISPLAY/WAYLAND_DISPLAY #355

@pmerlin1

Description

@pmerlin1

Problem

On WSL2 with WSLg enabled (the default on Windows 11), shouldLaunchBrowser() in workspace-server/src/utils/secure-browser-launcher.ts returns true because WSLg pre-populates DISPLAY and WAYLAND_DISPLAY. The server then takes the GUI path and calls open() / xdg-open for OAuth, which from WSL is unreliable — typically no browser the user is actually watching surfaces, and getAuthenticatedClient() ends up stalling until its ~5-minute timeout.

The headless flow added in #227 is the correct path for WSL2, but it is never reached because WSL is misclassified as GUI-capable.

Reproduce

  1. Run the MCP server inside WSL2 on Windows 11 (WSLg defaults).
  2. Confirm echo \$DISPLAY and echo \$WAYLAND_DISPLAY both return values.
  3. Clear credentials and trigger any tool that requires fresh auth (e.g. gmail.search).
  4. The server takes the GUI-launch branch and hangs / times out instead of returning the headless OAuth URL.

Proposed fix

In shouldLaunchBrowser(), treat WSL as headless by checking for WSL_DISTRO_NAME or WSL_INTEROP (set by WSL2 but not by native Linux). This routes WSL users through the existing headless flow.

Happy to send a small PR (one function, plus a test) if the maintainers are open to this approach.

Environment

  • WSL2 on Windows 11 (WSLg defaults)
  • Latest `main`

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions