Skip to content

fix(engine): audio effects launch Chrome like every other render, sandbox retry included - #6550

Merged
miguel-heygen merged 1 commit into
mainfrom
fix/audiofx-shared-launch
Oct 27, 2026
Merged

miguel-heygen merged 1 commit into
mainfrom
fix/audiofx-shared-launch

Conversation

@miguel-heygen

@miguel-heygen miguel-heygen commented Oct 27, 2026 •

Copy link
Copy Markdown
Collaborator

What changes

Audio effects started Chrome with its own two flags and no retry. Inside an agent's macOS seatbelt Chrome is refused at startup and the effect render fails with Protocol error (Target.setDiscoverTargets): Target closed, while the CLI's own browser launch already recovers from that case.

  • The sandbox launch policy (inAgentSandbox, machServiceDenied, oneProcessOverPipe, the remediation message) moves from the CLI into packages/engine/src/services/sandboxLaunch.ts, so the engine owns it once. The CLI imports it from @hyperframes/engine.
  • The engine's Chrome launch (launchBrowser in browserManager.ts) launches one process over a pipe when the host names a seatbelt, and retries once that way when Chrome is refused its mach service or a pipe launch closes on macOS. This covers render capture as well as audio effects.
  • Audio effects ask for buildChromeArgs(...) in software GPU mode instead of a private flag list, so they get the same flags (--disable-dev-shm-usage and the rest) as every other launch.

Linux and cloud renders

  • The seatbelt retry and its remediation message are macOS only (process.platform === "darwin", and inAgentSandbox / pipeLaunchClosedOnMac were already macOS only). On Linux the engine launch passes the same options as main, retries nothing and throws the same errors. browserManager-seatbelt.test.ts pins it: with the platform set to Linux, a refused mach service and a closed pipe each cause exactly one launch with no --single-process, and the original error comes back unchanged. The existing browserManager-ownerMarker.test.ts already pins the launch args byte for byte.
  • render.ts and the CLI launch only change where the macOS helpers are imported from.
  • The one Linux change is audio effects: Chrome now gets the shared flags (software GPU: --disable-dev-shm-usage, swiftshader ANGLE, --no-zygote, the throttling and background flags) on top of the --no-sandbox and autoplay flags it had. It is still one page, no GPU work, and the same flags every capture browser already uses. Measured on the devbox, a 20 s tone through a peaking + reverb chain (applyAudioFxChain, each run a fresh process, main's two flags vs this branch, interleaved, 3 runs each):
cold (first call, includes Chrome start) warm (second call)
main 933, 764, 793 ms 673, 664, 663 ms
branch 788, 796, 772 ms 664, 667, 680 ms

No difference beyond noise. I timed the audio-fx step only, not a full render; the step is the only thing this PR changes for Linux, so a total render moves by at most that step's difference (under 150 ms cold, none warm).

Not reproduced

The field report (CLI 0.8.206, macOS arm64, run from an in-app agent) is not reproduced. Nothing here proves that was the cause: it is the hypothesis that fits the error text and the launch path, and it is the only engine launch that skipped the shared flags and the sandbox recovery.

Tests

  • audioFxLaunch.test.ts: audio effects call acquireBrowser with exactly buildChromeArgs(...).
  • browserManager-seatbelt.test.ts: a refused mach service is retried once with --single-process over a pipe; a host that names a seatbelt launches that way first.
  • Both fail with the fix reverted and pass with it; the engine browser and audio effect suites pass three runs in a row.

@heygengenesis heygengenesis Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verdict: REQUEST CHANGES · 1 blocker · 0 important · 0 nits · head 783f37ea

FX_BROWSER_ARGS is computed when the module loads, which makes importing the engine barrel spawn a subprocess. ↓ inline

Scope

Read the 9 changed files. sandboxLaunch.ts is a 100% rename with no CLI imports, and no sandboxDenied importers remain. On Linux, launchInsideSandbox passes main's options through and rethrows. The darwin remediation runs before explainChromeLaunchFailure. I did not wait for CI because the blocker stands either way.

— Claude

@github-actions

github-actions Bot commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

Edit accuracy: accurate 271 (base branch 271), smooth 181 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 (0)

@heygengenesis heygengenesis Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verdict: APPROVE — 1 resolved, 0 open, 0 new · 783f37e → c244394

…dbox retry included

Audio effects launched Chrome with its own two flags and no retry, so inside
an agent's macOS seatbelt Chrome died at startup with "Target closed" while
the CLI's own browser launch recovered. The sandbox launch policy now lives
in the engine; the engine's Chrome launch retries once in one process over a
pipe when the sandbox refuses it, and audio effects use the shared Chrome
flags in software GPU mode. The CLI imports the same policy from the engine.
@miguel-heygen
miguel-heygen force-pushed the fix/audiofx-shared-launch branch from c244394 to 1e84ba4 Compare October 27, 2026 12:11

@heygengenesis heygengenesis Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verdict: APPROVE — 0 resolved, 0 open, 0 new · c244394 → 1e84ba4 (rebase onto main; PR patch identical apart from launch.ts import context)

@miguel-heygen
miguel-heygen added this pull request to the merge queue Oct 27, 2026
Merged via the queue into main with commit c1da4a7 Oct 27, 2026
80 checks passed
@miguel-heygen
miguel-heygen deleted the fix/audiofx-shared-launch branch October 27, 2026 13:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant