[jrusso1020]

When Chrome fails to start, the startup diagnosis now relaunches it with the env the failed attempt had, not one rebuilt from process.env. Before this, a launch that dropped WAYLAND_DISPLAY or the SwiftShader Vulkan pins was diagnosed with them restored, so the diagnosis could describe a different failure.

Claude Opus 5.5

Change

• explainChromeLaunchFailure takes { signal, env } as its 4th argument (it was a bare signal). diagnoseChromeStartup spawns with buildChromeLaunchEnv(options.env). When no env is given it still falls back to process.env, and the allowlist still applies either way.
• Engine launchBrowser passes the launchEnv(fingerprint) result that the attempt launched with. That env has the Wayland display removed on WSL hardware mode and the Vulkan pins removed for SwiftShader.
• CLI withStartupDiagnosis passes the attempt's options.env, the same input launchOwnedBrowser filters.
• Docstring updated: the diagnosis replays the failed launch's flags and env.

Tests

• Engine (browserManager-sandboxRetryDiagnosis.test.ts): VK_DRIVER_FILES is set and a SwiftShader launch fails. The test asserts the diagnosis gets exactly the env the attempt launched with, and that env has no pin.
• CLI (launch.sandboxRetryDiagnosis.test.ts): a real end-to-end probe. WAYLAND_DISPLAY is set in process.env, the launch env omits it, and a fake browser prints its WAYLAND_DISPLAY. The diagnosis must not see the process.env value.
• Mutation check: each test fails when its piece of the fix is reverted (engine call without env, diagnosis spawn back on buildChromeLaunchEnv(), CLI call without env), and passes with the fix. The engine services suite passes (2215 tests), and so do the CLI launch tests.

Refs #7623

🤖 Generated with Claude Code

— Rames Jusso

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 94 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

Unstable (2)

• seqplainkeys-none-px-r0-root-z100: tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true
• seqrotatenudge-none-px-r0-root-z100: tracking 0.03, pressJump 0, drop 0, reload 3.07, render 0.04, renderKey -, undo false, teleport true / tracking 0.03, pressJump 0, drop 0, reload 0, render 0.08, renderKey -, undo true, teleport true / tracking 0.03, pressJump 0, drop 0, reload 0, render 0.08, renderKey -, undo true, teleport true

[heygengenesis]

Verdict: APPROVE · 0 blocker · 0 important · 0 nits · cb374285

This closes the #7629 diagnosis-env nit. Both callers of explainChromeLaunchFailure now pass the attempt's env: the engine passes launchEnv and the CLI passes options.env. Running that env through buildChromeLaunchEnv again is safe because the base already has the passthrough fix. An env of undefined still falls back to process.env. The switch from a positional signal to an options object leaves no stale callers, and CI is green.

— Genesis