[juliusmarminge]

Problem

vp run scenarios and vp run scenarios:prove (added in #34007) could not run on machines that resolve localhost to ::1 first, such as the Linux worker VMs. e2e waited on http://127.0.0.1:<port> for its full 300-second startup timeout on each commit and then reported "could not run", although the app had started.

Confirmed on a fresh worker VM at 3a8c250cb0: the web dev server binds localhost, which there is [::1] only.

$ getent hosts localhost
::1             localhost ip6-localhost ip6-loopback
➜  Local:   http://localhost:35054/        # ss: [::1]:35054
127.0.0.1 -> no answer        [::1] -> 200

Setting HOST from outside cannot fix it: the dev runner deletes HOST in web modes.

Fix

The runner and the app now agree on one address by construction.

• scripts/e2e.config.ts has one LOOPBACK constant (127.0.0.1) used for the app URL, the ready URL, and passed to the start script.
• scripts/scenarios/start-app.ts starts the server (dev:server) and the web dev server (dev:web) separately instead of the combined dev mode, and passes the web one --host <that address> and both the same --dev-url. The allowed origin uses the same address.
• If the web port comes up on the other loopback address anyway, the start script says so and exits, so e2e does not wait out its timeout. This branch of the code was not exercised: with --host honoured it cannot happen on current commits.

The change is in the start script, not in apps/web/vite.config.ts, because a proof runs the app of an older base commit with this checkout's scripts.

Proof, on a fresh worker VM

Branch at 53698b6cf9, after vp i:

• vp run scenarios --target web: 2 passed in 40 s, browser download included. The app log shows Local: http://127.0.0.1:45959/.
• vp run scenarios:prove scripts/scenarios/add-project-tab-reaches-submit.e2e.ts --base e509db3a2f^ --head e509db3a2f --upload-command "ghdrop upload": exit 0 in 106 s (it took 11.5 minutes to fail before).

{
  "failsOnBase": true,
  "passesOnHead": true,
  "baseSha": "80e62619f5c01d84579bcf70ea6d566712007412",
  "headSha": "e509db3a2f21b8e291d05ef11789c6a4ff662e9c",
  "verdict": "Proven: the scenario fails on base `80e62619f5` and passes on head `e509db3a2f`."
}

	Base 80e62619f5	Head e509db3a2f
Result	❌ failed ASSERTION_FAILED: expect.toBeFocused failed	✅ passed
after tab

The same two web scenarios also pass on a machine where localhost resolves to 127.0.0.1.

Also

The doc gains the command that fetches e2e's browser ahead of time, for a machine image. Verified on the VM: after it, a run downloads nothing.

node scripts/node_modules/playwright-core/cli.js install --only-shell chromium ffmpeg

Not covered

• The iOS target was not rerun; its start path (mobile mode) is unchanged.
• The Vite proxy still targets the server at localhost while the server binds 127.0.0.1. It worked on the IPv6-first VM (Node tries both addresses), as it does in ordinary dev there.

vp run check:changed passes.

Work by Claude Fable 5.2 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 5379f98

Macroscope's review found this PR approvable — The web scenario harness now uses an explicit IPv4 loopback address for startup and readiness, avoiding IPv6-first localhost mismatches. Effects are confined to test startup; production defaults and mobile startup remain unchanged.

^{You can add or adjust custom eligibility rules. Learn more.}