fix(e2e): relaunch when the renderer comes up without a frame pipeline

[Ashin-LX-98]

Problem

About one launch in four on a self-hosted Windows runner comes up with no frame production at all. The DOM reads perfectly healthy under page.evaluate — correct geometry, nothing covering the element — while requestAnimationFrame never fires.

Playwright's actionability check compares an element's bounding box across two rAF callbacks, so the first click of every spec hung for 30s on:

- waiting for getByTestId('nav-install')
  - locator resolved to <button ... data-testid="nav-install" ...>
- attempting click action
  - waiting for element to be visible, enabled and stable

intercepts pointer events never appears, and element is visible, enabled and stable never prints. There is nothing in the trace to explain it.

Why relaunching, and not waiting or retrying

The state never recovers. Measured on the affected machine:

• Forcing show + moveTop + focus moves isFocused 0→1 but leaves the window at 0 fps, 4/4, and the click still fails.
• isVisible, isMinimized and isFocused read identically on stalled and healthy windows.
• Frame rate is a clean binary — ~31 fps or 0, never anything between — so the renderer either composites or never gets a compositing context.

There is nothing to wait for and nothing to poke, so a longer timeout or a Playwright-level retry only spends more time on a launch that cannot succeed. Chromium switches were ruled out too: this box has group policy injecting disable-features, which silently replaces anything passed on the command line.

Changes

All in e2e/fixtures.ts; no product code.

• producesFrames(page) — wait for one rAF callback; 10s without one means this launch has no frame pipeline.
• launcher fixture — launch, get the main window, verify frames; relaunch up to 5 times otherwise. Stalls are independent between launches, so five attempts put an all-stalled run near 0.1%, and a relaunch reuses the warm HOME rather than repeating the runtime download. Every failure path closes its candidate — an abandoned Electron process holds the isolated HOME open and poisons the next attempt.
• First-run dismissal moved from the page to the context, where it lands before the main window's first load. That drops the reload round trip the page fixture previously needed to apply it.
• app and page now read from one internal fixture, so both refer to the same proven launch.

Verification

19 launches on the affected machine:

Stalls	5 (26.3%)
Recovered by relaunch	5 / 5
Exhausted all 5 attempts	0
nav-install click timeouts	0 (was ~45%)
Reloads	0 / 14
Specs passing	14 / 14

Slowest recovery added ~2 min to a spec budgeted 15.

Scope

This does not fix the claude and opencode Windows failures that have been red on the nightly for over a week — those are a separate, real defect on a different code path. After this lands they will still fail, but with a legible reason instead of an unexplained 30s timeout.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
openagents-workspace	Ready	Preview	Sep 7, 2026 9:07am UTC