[Bug]: playwright-cli v0.1.18 crashes on startup on Windows with libuv assertion (v0.1.17 works)

[dexterfire]

Description

@playwright/cli v0.1.18 crashes immediately on any command on Windows, including --version:

Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 94

Reproduces consistently (4/4 attempts) via:

• npm shim in PowerShell (playwright-cli --version)
• npm shim in cmd.exe
• direct node invocation: node %APPDATA%\npm\node_modules\@playwright\cli\playwright-cli.js --version

Downgrading to v0.1.17 fixes it completely (5/5 successful runs, including a full browser session open/snapshot/close test).

Note: one transient identical crash was observed on the very first run of v0.1.17 right after the global reinstall; all subsequent runs are stable. Suspect a startup race in the update-check / installed-skill check path (cf. #454, which fixed cacheFile() breakage introduced by the same 1.63.0-alpha roll that shipped in 0.1.18).

Steps

1. npm i -g @playwright/cli (installs 0.1.18)
2. playwright-cli --version

Expected behavior

The CLI prints its version.

Actual behavior

Immediate libuv assertion crash, no output:

Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 94

Environment

• OS: Microsoft Windows [Version 10.0.26200.8875]
• Node: v24.18.0 (system Node invoked by the npm shim)
• @playwright/cli 0.1.18 (bundles playwright/playwright-core 1.63.0-alpha-2026-08-05) — crashes
• @playwright/cli 0.1.17 (bundles playwright/playwright-core 1.62.0-alpha-1783623505000) — works

[dcrousso]

thanks for the detailed report!

this looks like the CLI update check triggering a known Node 24 bug on Windows nodejs/node#56645

could you please try 0.1.18 with the update check disabled and confirm whether this avoids the crash?

$env:NO_UPDATE_NOTIFIER = '1'
playwright-cli --version

[Darkslayer3324j]

Independent confirmation on a second machine — NO_UPDATE_NOTIFIER=1 avoids the crash.

Without it (default), 4/4 crash:

$ node %APPDATA%\npm\node_modules\@playwright\cli\playwright-cli.js --version
0.1.18
Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76
# exit code -1073740791 (0xC0000409), 4 of 4 runs

With NO_UPDATE_NOTIFIER=1, 5/5 clean:

$ $env:NO_UPDATE_NOTIFIER = '1'
$ node %APPDATA%\npm\node_modules\@playwright\cli\playwright-cli.js --version
0.1.18
# exit code 0, 5 of 5 runs

Two details that may help narrow it:

1. The version string is printed before the crash in every failing run. The command does its work and then aborts, so this looks like a teardown/exit race rather than a startup failure — consistent with the handle already being in UV_HANDLE_CLOSING when the update check's async handle is touched during shutdown.

2. The assertion line differs from the original report — async.c line 76 here vs line 94 for dexterfire. Different Node 24 patch releases, so this isn't pinned to one build:

	dexterfire	this machine
Node	v24.18.0	v24.13.1
async.c line	94	76
Windows	10.0.26200.8875	10.0.26200
@playwright/cli	0.1.18	0.1.18

So the trigger reproduces across Node 24 patch versions, which fits nodejs/node#56645 being the underlying cause rather than something specific to one Node build.

Happy to test a patch that guards the update check on Windows if that's the direction you'd like to take.

[Darkslayer3324j]

Dug into why this reproduces on every invocation rather than once a day, and there turn out to be two separate bugs. The second one is a one-character fix.

The update check never caches, so it fetches every run

cacheFile() passes registry.defaultRegistryDirectory to path.join without calling it:

function cacheFile() {
  return path.join(registry.defaultRegistryDirectory, 'cli-update-check.json');
}

It's a function, not a string:

$ node -e "const {registry}=require('playwright-core/lib/coreBundle');
           console.log(registry.defaultRegistryDirectory)"
[Function: defaultRegistryDirectory]

$ node -e "... path.join(registry.defaultRegistryDirectory,'x.json')"
TypeError: The "path" argument must be of type string.
           Received function defaultRegistryDirectory

So cacheFile() throws, and both readCache() and writeCache() swallow it in a bare catch {}. readCache() always returns undefined, stale is therefore always true, and writeCache() never lands. Instrumenting 0.1.18 confirms it — cli-update-check.json is never created, and every run reports a cache miss followed by a network fetch:

run1: CRASH :: cache=MISS | performing network fetch
run2: CRASH :: cache=MISS | performing network fetch
run3: CRASH :: cache=MISS | performing network fetch

That means @playwright/cli hits registry.npmjs.org on every command, not once per 24h as ONE_DAY_MS intends. That's a bug in its own right — latency on every invocation plus needless registry load — and here it's what turns the Node 24 crash from a once-a-day annoyance into a total blocker.

Fix

-  return path.join(registry.defaultRegistryDirectory, 'cli-update-check.json');
+  return path.join(registry.defaultRegistryDirectory(), 'cli-update-check.json');

With that applied, the cache persists and the fetch happens only when genuinely due:

run1: CRASH :: cache=MISS | performing network fetch
run2: ok    :: cache=HIT
run3: ok    :: cache=HIT

C:\Users\hp\AppData\Local\ms-playwright\cli-update-check.json is now written (52 bytes).

The crash itself is fetch()

Short-circuiting fetchLatestVersion() to return undefined, changing nothing else, removes the crash entirely — 4/4 clean. So it is the fetch() call specifically, not the cache read/write or the rest of notifyAboutUpdate().

Swapping that one call to node:https with keepAlive: false also avoids it — 5/5 clean with the update check on and the fetch genuinely performed each time. That sidesteps undici's keep-alive sockets being torn down at exit, which is what trips the assertion under nodejs/node#56645.

I'm not assuming that's the fix you'd want — dropping fetch() for one call is a bit blunt, and you may prefer to wait on the Node fix, or gate the check on Windows. But it does confirm where the crash originates.

Suggested split

The cacheFile() fix stands on its own regardless of the Node bug: it's correct, it's one character, and it cuts registry traffic from every-invocation to once-a-day. That alone takes this from "crashes constantly" to "crashes once a day", which is the difference between unusable and a papercut.

Happy to open a PR for the cacheFile() fix, and separately for the fetch() change if you want it. Just say which.

_{All output above from local runs against @playwright/cli@0.1.18 on Windows 10.0.26200 / Node v24.13.1. Investigated with AI assistance; every command is reproducible from a clean install.}

[Darkslayer3324j]

Hi Devin Rousso (@dcrousso) — correction to my last comment, and apologies for the noise.

I offered to open a PR for the cacheFile() fix without checking whether it was already done. It was: #454 landed it on 2026-08-24, exactly the defaultRegistryDirectory() call I described. I should have looked before offering. Sorry about that.

The timeline does explain the symptom, though, so I don't think the finding is wasted:

	date
0.1.18 published to npm	2026-08-06
#454 merged	2026-08-24

0.1.18 shipped eighteen days before the fix, so everyone currently on the published build still has the broken cache path. That's why this reproduces on every invocation rather than once a day — the update check can never record that it ran, so it refetches every time. My instrumented run of the published build showed cache=MISS plus a network fetch on all three runs, and cli-update-check.json never being created, which lines up.

The part I think is still open: fetch() is still on main (lines ~60-63). So once #454 ships, this goes from crashing on every command to crashing on the first command of each day — a big improvement, but not gone. The libuv assertion comes from that call specifically: short-circuiting fetchLatestVersion() to return undefined and changing nothing else gives 4/4 clean runs.

Swapping just that one call to node:https with keepAlive: false also clears it — 5/5 clean with the update check on and the fetch genuinely performed each time. That avoids undici's keep-alive sockets being torn down at exit, which is what trips nodejs/node#56645 on Windows.

I'm happy to put that up as a PR against microsoft/playwright-cli if it's the direction you want. I can also see the argument for leaving it and waiting on the Node fix, or for skipping the check on Windows under Node 24 — you'd know better which fits. Just let me know, and this time I'll check for an existing fix first.

_{Environment: Windows 10.0.26200, Node v24.13.1, @playwright/cli@0.1.18. Investigated with AI assistance; the commands are reproducible from a clean install.}

[dcrousso]

this has been fixed in Node so please to the latest LTS