playwright "Executable doesn't exist at" ms-playwright cache in CI: how to install browsers

Install the browsers in CI before the tests run. CI runners start from a clean image every time, so the Playwright browser binaries your laptop has are simply not there - the test run fails at launch with the "Executable doesn't exist" path error. Add the Playwright browser install command as its own step in your CI workflow, before the test step, and cache the browser download directory so later runs do not re-download gigabytes every time. One gotcha: the install must run with the same user and the same browser path the tests use, or the cache lookup misses and you are back to square one.

playwright "Executable doesn't exist at" ms-playwright cache in CI: how to install browsers

Steps

1. Add a browser install step to your CI workflow before the test step: run the Playwright install command for the browsers your config uses (usually chromium, or all three). Keep it as a separate step so its failure is obvious. Expected: the CI log shows browsers downloading and installing, and the path error is gone.

2. Pin the Playwright version in your lockfile and install the matching browsers. A version drift between the npm package and the installed browsers causes cryptic launch failures that look like a different bug. Expected: the installed browser build matches the Playwright package version.

3. Cache the browser directory between CI runs using your provider's cache action keyed on the lockfile hash. This turns a multi-minute download into a cache restore. Expected: a second CI run restores browsers from cache instead of downloading them.

4. If your CI image already ships browsers (some Docker images do), either use that image or point Playwright at the system browsers - but do not do both half-heartedly, or the path lookup misses. Expected: exactly one browser source is configured: downloaded cache or system browsers, not a mix.

5. Verify with a clean run: clear the cache once and watch a full cold install succeed, so you know the pipeline works without a warm cache. Expected: a cold-cache run installs browsers and goes green end to end.

Use this when

• "Executable doesn't exist at" with an ms-playwright path in CI
• CI fails before the first test executes
• you need browsers installed on ephemeral CI runners

Not for this skill when

• browsers installed but crashing on launch (that is a missing system dependency problem - different fix)
• the same error on your laptop (just run the install command locally; no CI involved)

Variant phrasings

playwright install browsers CI

The general form of this task. The error string is the specific symptom; the fix is the install step plus caching.

ms-playwright cache not found

Same error, shorter phrasing. Check the browser path and the installing user before anything else.

Why it happens

Playwright downloads its own patched browser binaries into a cache directory (the ms-playwright folder) on first install. Your laptop has them from when you set the project up; CI runners are fresh machines that only have what your workflow installs. If no workflow step installs the browsers, the first test to launch one fails with the missing-executable error - before any of your test code even runs. Caching the directory between runs avoids paying the download cost on every commit.

Edge cases

• monorepos where the install runs in a different package directory than the tests: the browser path is resolved per project, so run install where the tests run
• self-hosted runners with a persistent disk: you can install once and skip the CI step, but document it - the next person to rebuild the runner will hit this error
• browser install needs system dependencies too on bare Linux images: the install command has a flag for OS deps, and without them the browsers install but will not launch

Provenance

Resolved from the public thread: https://vectle.com/posts/pst6zO3Akmgm-9q1rj_shPfg