[WSL2] userDataDir path converted to Windows format causes directory creation with literal backslashes on Linux

[The-Thought-Magician]

Before submitting an issue, please:

• Check the documentation for relevant information
• Search existing issues to avoid duplicates

Environment Information

• Language/SDK: TypeScript
• Stagehand version: 3.0.7 (regression from 3.0.5)
• AI Provider: Google (Gemini)
• Model: google/gemini-2.5-flash
• Platform: WSL2 (Ubuntu 24.04 on Windows)

Issue Description

  After upgrading from Stagehand 3.0.5 to 3.0.7, the userDataDir path is being converted to Windows format (\\wsl.localhost\...) and then used for filesystem operations on Linux. This creates a directory with literal backslashes in its name instead of using the correct Linux path.

  Expected: Chrome profile directory at /home/user/project/chrome-profile

  Actual: Directory created at /home/user/project/\\wsl.localhost\Ubuntu-24.04\home\user\project\chrome-profile (literal backslashes in filename)

  This is a regression introduced by PR #1462 which changed how userDataDir is passed to chrome-launcher.

Steps to Reproduce

1. Run on WSL2 (Ubuntu)
2. Create a Stagehand instance with a custom userDataDir:
   const stagehand = new Stagehand({
   env: "LOCAL",
   localBrowserLaunchOptions: {
   userDataDir: path.join(process.cwd(), "chrome-profile"),
   executablePath: "/usr/bin/chromium-browser",
   },
   });
   await stagehand.init();
3. Observe that a directory with backslashes in its name is created in the project root

Minimal Reproduction Code

// Your minimal reproduction code here
 Minimal Reproduction Code

  import { Stagehand } from "@browserbasehq/stagehand";
  import path from "path";

  const stagehand = new Stagehand({
    env: "LOCAL",
    model: {
      modelName: "google/gemini-2.5-flash",
      apiKey: process.env.GOOGLE_API_KEY,
    },
    localBrowserLaunchOptions: {
      headless: false,
      executablePath: "/usr/bin/chromium-browser",
      userDataDir: path.join(process.cwd(), "chrome-profile"),
    },
  });

Root Cause Analysis

In chrome-launcher, WSL2 is detected and paths are converted:

// chrome-launcher converts path for Chrome's --user-data-dir flag
flags.push(--user-data-dir=${isWsl2 ? toWin32Path(this.userDataDir) : this.userDataDir});

The conversion to Windows path (\wsl.localhost\Ubuntu-24.04...) is correct for passing to Chrome. However, somewhere in the code path (likely in Stagehand v3's launchLocalChrome or related functions), this converted Windows path string is being used for Node.js filesystem operations (mkdir, etc.) on Linux, where backslashes are valid filename characters.

In 3.0.5: userDataDir was manually added to chromeFlags, bypassing chrome-launcher's WSL handling.

In 3.0.7: userDataDir is passed to launch() options, triggering chrome-launcher's WSL path conversion which then leaks into filesystem operations.

---

Related Issues

• fix: correctly pass in userDataDir to chrome launcher #1462 (PR that introduced this regression)
• Storage state persistence broken in Stagehand v3 - userDataDir doesn't work, storageState() method missing #1250 (userDataDir persistence issues)
• (Local browser session reuse) No option to persist Stagehand / Playwright userDataDir #794 (userDataDir session reuse)

---

Workaround

Pin to Stagehand 3.0.5:
"@browserbasehq/stagehand": "3.0.5"