Repository navigation
fix(engine): audio effects launch Chrome like every other render, sandbox retry included - #6550
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
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
Contributor
Edit accuracy: accurate 271 (base branch 271), smooth 181 of thoseThe gate passes. Quarantined, measured but not gated (0) |
miguel-heygen
enabled auto-merge
October 27, 2026 11:48
…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
force-pushed
the
fix/audiofx-shared-launch
branch
from
October 27, 2026 12:11
c244394 to
1e84ba4
Compare
2 of 4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.inAgentSandbox,machServiceDenied,oneProcessOverPipe, the remediation message) moves from the CLI intopackages/engine/src/services/sandboxLaunch.ts, so the engine owns it once. The CLI imports it from@hyperframes/engine.launchBrowserinbrowserManager.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.buildChromeArgs(...)in software GPU mode instead of a private flag list, so they get the same flags (--disable-dev-shm-usageand the rest) as every other launch.Linux and cloud renders
process.platform === "darwin", andinAgentSandbox/pipeLaunchClosedOnMacwere already macOS only). On Linux the engine launch passes the same options as main, retries nothing and throws the same errors.browserManager-seatbelt.test.tspins 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 existingbrowserManager-ownerMarker.test.tsalready pins the launch args byte for byte.render.tsand the CLI launch only change where the macOS helpers are imported from.--disable-dev-shm-usage, swiftshader ANGLE,--no-zygote, the throttling and background flags) on top of the--no-sandboxand 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):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 callacquireBrowserwith exactlybuildChromeArgs(...).browserManager-seatbelt.test.ts: a refused mach service is retried once with--single-processover a pipe; a host that names a seatbelt launches that way first.