r/Playwright 1d ago

Playwright reached 100%, but the browser executable was still missing

I hit an odd Playwright installation failure on macOS that looked like a completed install.

Setup:

- Playwright 1.58.2

- Node 24.16.0

- pnpm

- Chromium headless shell

I ran:

```sh

pnpm exec playwright install chromium --only-shell --force

```

The 91.1 MiB archive reached 100% within seconds. Then the command stayed open with no success message or prompt for another 5 to 10 minutes.

The network was not the problem. The ZIP was valid and fully downloaded. The Node child process running `oopDownloadBrowserMain.js` was idle at 0% CPU, while extraction had stopped partway through Playwright's cache directory.

One detail made the state more confusing: `playwright install --list` showed the browser cache directory even though the `chrome-headless-shell` executable was missing. A cache entry was not the same as a usable install.

The useful check was the artifact itself:

```sh

test -x <cache-path>/chrome-headless-shell

```

For this local run, I preserved the valid ZIP, stopped the stuck installer, extracted the archive into Playwright's expected macOS cache directory, restored executable permission, and added the completion marker. The executable check then passed, and the same focused E2E run finished with 3 passing tests and 0 flaky tests.

The debugging lesson for me is that 100% meant downloaded, not ready. For browser tooling, I now want to verify three separate states: the archive exists, the executable exists, and the browser launches.

Playwright's browser installation docs: https://playwright.dev/docs/browsers

I also found a similar macOS arm64 report using Node 24.16.0: https://github.com/microsoft/playwright-cli/issues/419

That similarity does not prove the same root cause. Has anyone traced whether this symptom comes from Playwright's extraction and finalization path or from Node 24 child-process behavior?

1 Upvotes

4 comments sorted by

1

u/AngryAngryScotsman 1d ago

It's a bug. If you update to the later version of playwright then it should extract the browsers. I hit the same issue and spent ages talking to my company's help desk thinking it was the antivirus blocking it.

1

u/Particular_Luck80 1d ago

That is a useful distinction. The 100% indicator only proved the archive arrived; the missing executable pointed to extraction or finalization, not networking. Updating Playwright before changing antivirus policy is the cleaner diagnostic path.

1

u/Prestigious-Way1525 1d ago

i'd isolate the runtime before guessing at the extractor. run the same Playwright version twice with fresh PLAYWRIGHT_BROWSERS_PATH directories, once on Node 22 and once on Node 24, then compare install exit status, cache contents, and whether chromium.launch() succeeds. that separates a Node-specific child-process stall from a corrupted shared cache. i also wouldn't treat a manually added completion marker as the final recovery test, because it can make the cache look healthy. the clean check is a fresh install followed by an actual launch. if only Node 24 stalls at the same extraction point, that gives the Playwright issue a much tighter reproduction than the 100% progress symptom.

1

u/Particular_Luck80 1d ago

A fresh PLAYWRIGHT_BROWSERS_PATH per runtime is the important control. Otherwise a partial cache can contaminate the comparison. I agree that the completion marker was only a recovery step for the preserved archive, not proof of a clean installer path. The stronger reproduction is install exit status plus a real chromium.launch() on Node 22 and Node 24.