Error: Environment not initialized. Run `wp-env start` first.

[westonruter]

I'm starting to see this error pop up in some repos which are using this action:

Error: Environment not initialized. Run wp-env start first.

For example: https://github.com/WordPress/performance/actions/runs/26495321767/job/78022203697?pr=2496

[swissspidy]

Strange. Didn't see any of that here. Maybe one more reason to switch to Playground.

[westonruter]

(Co-authored with Claude Code. The investigation, bisection, and wording below were done in a session with the assistant.)

Root cause: bisected via three CI experiments

Got the full picture by running three controlled experiments against WordPress/performance#2496, which kept hitting this failure on a stable basis.

Reproduction

100% correlation between failure and GitHub Actions ubuntu-24.04 runner image version. From a mixed-image matrix run (#26545998824 on WordPress/performance):

Runner image	Result
ubuntu24/20260518.149 (May 18, Node 24.15.0)	✅ success on all jobs
ubuntu24/20260525.161 (May 25, Node 24.16.0)	❌ Environment not initialized on all jobs

Same workflow, same @wordpress/env version (11.6.0), same plugin-check-action SHA — the only variable was which runner image GitHub assigned. That's why the failure looks "intermittent" right now: it's GitHub mid-rollout of the new image. Once rollout completes, every run will fail.

(@wordpress/env 11.5.0 → 11.6.0 → 11.7.0 has no source changes in packages/env/ — we diffed the tarballs. Only CHANGELOG.md/README.md. So it's not a wp-env release regression in the strict sense; it's a latent wp-env bug that the new runner image exposes.)

Bisection

To find what specifically triggers it, this action's logic was forked inline in WordPress/performance:fix/issue-1920 and ran three experiments:

Experiment 1: added "testsEnvironment": false to the auto-generated .wp-env.json.

• Hypothesis: bug is in the deprecated dual-environment startup path.
• Result: ❌ symptom unchanged. The deprecation warning is gone from the log (proving config was honored), but wp-env still silently exits 0.
• Conclusion: dual-env path isn't the trigger.

Experiment 2: dropped the --update flag from wp-env start.

• Hypothesis: Gutenberg's CI runs wp-env start (no --update) successfully on the same broken image, so --update might be the trigger.
• Result: ❌ symptom unchanged.
• Conclusion: --update isn't the trigger either.

Experiment 3: removed the URL-based plugin entry (https://downloads.wordpress.org/plugin/plugin-check.zip) from .wp-env.json and installed plugin-check via wp-cli after wp-env start completed.

• Hypothesis: Gutenberg's .wp-env.test.json doesn't have any URL plugins entries — it uses "plugins": ["."] and "core": "WordPress/WordPress" (git). Ours pulls a .zip from HTTP.
• Result: ✅ all matrix jobs went green on the new runner image.
• Conclusion: the trigger is the URL-plugin download path inside wp-env.

What this means

The bug lives in @wordpress/env's URL-source download path (the code that downloads zip plugins/themes from HTTP URLs). It silently exits the process with status 0 rather than erroring when this path runs on Node.js 24.16.0 / libuv 1.52.1. Likely candidate: the bundled got dependency is pinned at ^11.8.5 (last released April 2024), interacting badly with the libuv 1.52.1 update in Node 24.16.

I'll file a separate issue against WordPress/gutenberg (packages/env) for the underlying fix.

Suggested fix for plugin-check-action

This action is uniquely positioned to trip the bug because it auto-generates a .wp-env.json that always includes the plugin-check zip as a URL plugin:

plugin-check-action/action.yml

Line 114 in 18573eb

echo "{ \"core\": $WP_VERSION, \"port\": 8880, \"testsPort\": 8881, \"plugins\": [ \"https://downloads.wordpress.org/plugin/plugin-check.zip\" ], \"mappings\": { \"wp-content/plugins/$PLUGIN_SLUG\": \"$PLUGIN_DIR\" } }" >> .wp-env.json

Two options here, in order of preference:

1. Stop putting plugin-check in .wp-env.json at all. After wp-env start, run wp-env run cli wp plugin install plugin-check --activate. This is what we did in our local fork and it works on both old and new runner images. It also has the nice side effect of being faster (wp-env doesn't have to redownload the zip on every cache miss).

2. Verify the environment actually came up after wp-env start --update. The current step trusts the exit code; we now know wp-env can exit 0 without actually starting Docker. Adding a wp-env run cli wp cli info (or similar) right after wp-env start would convert the silent failure into a loud one, so the retry wrapper actually gets a chance to retry.

Doing option 1 alone is enough to unblock everyone. Option 2 is good defense-in-depth for the next time wp-env regresses in a way that doesn't propagate to the exit code.

Workaround for downstream consumers right now

If you're hitting this and need an immediate unblock: inline this action's steps in your workflow and drop the plugin-check URL entry from .wp-env.json, installing it via wp-cli post-boot. Example diff: https://github.com/WordPress/performance/pull/2496/files

[westonruter]

I opened an issue in Gutenberg to fix the issue upstream (maybe):

• wp-env: silently exits 0 without booting Docker when .wp-env.json contains URL sources (Node 24.16+) gutenberg#78762

[swissspidy]

Thanks Weston!