[chubes4]

Related issues

• Windows desktop E2E on build 23490 (E2E: Drop desktop site tests that repeat CLI E2E checks and merge the two adopt-directory tests #5311) failed in appearance.test.ts's beforeAll: the Add site dialog never closed because site creation died with a PHP fatal, Failed opening required '…\wp-includes/Requests/…'. The new site was missing WordPress files.
• The same job logs EBUSY: resource busy or locked, copyfile from Failed to set up dependency WordPress version on every Windows run (5–20 times per job in the eight Windows E2E logs checked: builds 23401, 23432, 23455, 23474, 23478, 23481, 23490). Until now it looked harmless; on 23490 it reached a site.

How AI was used in this PR

Claude (via the Pi coding agent in a Roadie session) traced the failure through the job log, wrote the fix and the tests, and confirmed the test fails on trunk's code. I reviewed the diff and the evidence.

Proposed Changes

Every CLI command runs setupServerFiles as middleware. When server-files/wordpress-versions/latest has no WordPress (first run, or a fresh E2E session), it copies the bundled wp-files/latest/wordpress into it. The app starts several CLI commands at once, so several processes copied into the same folder at the same time:

1. Two processes write the same file; on Windows one gets EBUSY. setupServerFiles logs that and carries on.
2. latest is a valid-looking install as soon as wp-includes/version.php lands, which happens early in the copy. Any process checking then sees WordPress there and skips its own copy.
3. site create then copies the incomplete latest into the new site, and PHP fails on the first missing file.

This copies into a staging folder beside latest (latest.partial-<pid>-<uuid>) and renames it into place, so latest only ever appears complete:

• If the rename fails because another process installed latest first, that copy is used and the staging folder is removed.
• If latest exists but has no version.php (an interrupted copy), it's removed and the rename is retried, up to 5 times with a short backoff. Another process can install its own copy in between; that copy is accepted.
• The newer-bundled-version path is unchanged apart from using the same install step: the old latest still moves to wordpress-versions/<version>.

This isn't only a CI problem: a user's first launch after installing or updating Studio runs the same concurrent commands.

Not changed here: downloadWordPress (the throttled update from wordpress.org) also copies straight into its target. It runs at most once a day, and nothing in the logs shows it racing, so it's left for a separate change if needed.

Testing Instructions

Primary evidence, the real path: Windows desktop E2E on this PR (build 23494) logged no EBUSY and no Failed to set up dependency WordPress version errors. Trunk's run of the same 37 tests (23478) logged 18 and 9. Every E2E and CLI E2E job passed.

npx vitest run apps/cli/lib/dependency-management/tests/setup-server-files.test.ts is one test on real temp folders. It starts from an interrupted earlier copy, runs eight setupServerFiles() calls at once, and watches latest while they run. It checks that latest never shows version.php before every file is there, and that it ends as one complete copy. On trunk's code it fails (31–32 partial sightings per run); with the fix it passes, 3 of 3 runs.

Pre-merge Checklist

• Windows E2E log has no Failed to set up dependency WordPress version errors.

[wpmobilebot]

📊 Performance Test Results

Comparing 0134e5f vs trunk

app-size

Metric	trunk	0134e5f	Diff	Change
App Size (Mac)	954.28 MB	954.28 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	0134e5f	Diff	Change
load	1215 ms	1212 ms	3 ms	⚪ 0.0%

site-startup

Metric	trunk	0134e5f	Diff	Change
siteCreation	6002 ms	5562 ms	440 ms	🟢 -7.3%
siteStartup	2861 ms	2874 ms	+13 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)