playwright-cli open creates session file on Windows, but session is immediately closed; snapshot fails and list --all shows closed session

[JiangHe12]

Environment

• OS: Windows
• Shell: PowerShell
• @playwright/cli version: 0.1.7
• Browser used: Chrome
• Workspace: C:\Users\12542

Expected behavior

According to the README, this flow should work:

playwright-cli -s=fresh_test open --headed --persistent https://www.baidu.com
playwright-cli list --all
playwright-cli -s=fresh_test snapshot

Expected result:

- open starts a reusable headed session
- list --all shows the session as open
- snapshot can connect to that session

## Actual behavior

- open launches the browser successfully
- a .session file is created
- but list --all shows the session as closed
- and snapshot fails with:

Error: Browser 'fresh_test' is not open. Run

  playwright-cli -s=fresh_test open

to start the browser session.

So the browser visibly opens, but the session is not reusable across CLI calls.

## Fresh reproduction

I tested this after a full reinstall.

### 1. Reinstall

npm uninstall -g @playwright/cli
npm install -g @playwright/cli@latest
playwright-cli --version

Output:

0.1.7

### 2. Clean daemon dir

I removed:

C:\Users\12542\AppData\Local\ms-playwright\daemon

Then recreated it empty.

### 3. Initialize workspace

cd C:\Users\12542
playwright-cli install

Output:

✅ Workspace initialized at `C:\Users\12542`.
✅ Found chrome, will use it as the default browser.

### 4. Open a named persistent session

playwright-cli -s=fresh_test open --headed --persistent https://www.baidu.com

This opens Chrome successfully.

### 5. List sessions

playwright-cli list --all

Output:

### Browsers
/:
- fresh_test:
  - status: closed
  - browser-type: chrome
  - user-data-dir: C:\Users\12542\AppData\Local\ms-playwright\daemon\93cdbc45b973767e\ud-fresh_test-undefined
  - headed: true

### 6. Try to use the session

playwright-cli -s=fresh_test snapshot

Output:

Error: Browser 'fresh_test' is not open. Run

  playwright-cli -s=fresh_test open

to start the browser session.

## Files created

Session file is present:

C:\Users\12542\AppData\Local\ms-playwright\daemon\93cdbc45b973767e\fresh_test.session

Its contents look like:

{
  "name": "fresh_test",
  "version": "1.60.0-alpha-1775951570000",
  "timestamp": 1776167380000,
  "socketPath": "\\\\.\\pipe\\pw-64008da6-cli-93cdbc45b973767e-fresh_test",
  "workspaceDir": "C:\\Users\\12542",
  "cli": {
    "persistent": true
  },
  "browser": {
    "browserName": "chromium",
    "launchOptions": {
      "assistantMode": true,
      "headless": false,
      "channel": "chrome",
      "cdpPort": 50621
    },
    "userDataDir": "C:\\Users\\12542\\AppData\\Local\\ms-playwright\\daemon\\93cdbc45b973767e\\ud-fresh_test-
undefined"
  }
}

Notably, userDataDir ends with ud-fresh_test-undefined, which may be related.

The corresponding error log file is empty:

C:\Users\12542\AppData\Local\ms-playwright\daemon\93cdbc45b973767e\fresh_test.err

## Additional notes

I also saw earlier runs where:

- playwright-cli open --headed ... opened Chrome successfully
- but later open failed with EADDRINUSE on the named pipe
- kill-all did not always clean up the stale daemon state

After cleaning the daemon directory and reinstalling, the reproducible core issue remains:

- browser opens
- session file exists
- session is immediately treated as closed

## Summary

This appears to be a Windows session/pipe lifecycle issue in playwright-cli:

- open successfully launches the browser
- session metadata is written
- but subsequent CLI calls cannot connect to the session pipe
- so the session is unusable across commands even though the browser opened

[JiangHe12]

I reproduced this again on Windows and I do not think the underlying bug is fixed yet.

What I confirmed is that open --headed --persistent can succeed, Chrome visibly opens, the session file is written,
and the Playwright daemon process (cliDaemon.js) plus chrome.exe are still running, but later CLI calls still report
the session as closed and snapshot fails with Browser '' is not open.

So this does not look like a simple launch failure. It looks more like a Windows session / named-pipe reattachment
issue: the browser is alive, metadata exists, but subsequent CLI invocations cannot reconnect to the session and
therefore treat it as closed.

I also found a workaround: if open is started from an elevated / out-of-sandbox context, then follow-up commands
like snapshot need to run in the same privilege context as well. When I matched the context, I could successfully
reuse the already-open browser. If I mixed contexts, list showed closed and reuse failed.

My conclusion: still reproducible on Windows, likely related to daemon/pipe/session reuse rather than browser launch
itself.

[pavelfeldman]

if open is started from an elevated / out-of-sandbox context, then follow-up commands
like snapshot need to run in the same privilege context as well. When I matched the context, I could successfully
reuse the already-open browser. If I mixed contexts, list showed closed and reuse failed.

Could you clarify, do things require matched context or do things require elevated AND matched context?