Repository navigation
fix(sandbox): don't crash the desktop when the VM helper is missing - #380
Merged
Merged
Conversation
`bun dev:desktop` on a Mac with Swift 6.4 (Command Line Tools 27) opened
"A JavaScript error occurred in the main process: spawn .../codev-vmm
ENOENT". Two causes:
- The vz provider spawned codev-vmm without an "error" listener. A spawn
that fails emits "error" and never "exit", so the event was an uncaught
exception in Electron's main process — triggered at launch by sandbox
autostart, which does not go through availability()'s helper check.
start() now fails with "sandbox VM helper is not installed (expected at
…)" (or the spawn error) instead.
- The helper was never built: Swift 6.4 defaults `swift build` to the
swiftbuild backend, which fails on Command Line Tools setups ("Could not
initialize build system ... Unknown error parsing property list"), and
predev deliberately treats a failed helper build as non-fatal.
build-vzhelper.ts now retries a failed build with `--build-system
native`, so toolchains whose default works are unaffected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3 tasks done
quickbeard
added a commit
that referenced
this pull request
Sep 25, 2026
…381) Release packaging (desktop prebuild → build-vzhelper.ts --universal) failed on Command Line Tools 27 / Swift 6.4: the helper's macOS 12 deployment target links Swift's back-compatibility libraries (libswiftCompatibility56, libswiftCompatibilityPacks), and this toolchain ships every one of them for arm64/arm64e only, so the x86_64 slice failed to link ("fat file missing arch 'x86_64'", undefined symbols). macOS releases had to be built by hand. When the toolchain's libswiftCompatibility56.a has no x86_64 slice, the Intel slice is now built with `-runtime-compatibility-version none`. The arm64 slice keeps the libraries, and a toolchain that still ships Intel copies keeps them for Intel too; the only cost is Intel Macs on macOS 12.0–12.2 running the helper without those runtime fixes. Also quiets the failed first attempt on the default build system before the `--build-system native` retry (#380), so a successful build no longer logs a wall of errors. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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.
Summary
bun dev:desktopon macOS with Swift 6.4 (Command Line Tools 27) showed:Two causes, both fixed here:
1. A failed helper spawn crashed the main process.
createVzProvider().start()spawnedcodev-vmmand listened forexit, stdout and stderr, but noterror. When the binary is missing, Node emitserrorand neverexit(ChildProcess._handle.onexit, the frame in the dialog), so it became an uncaught exception in Electron's main process.start()directly.availability(), which does check for the helper, is only consulted by the UI.start()now handleserror:availability()gives;failure()path, so the sandbox shows an error instead of crashing the app.2. The helper never got built.
predev.tsbuildscodev-vmmfor dev runs and deliberately treats failure as non-fatal. On Swift 6.4,swift builddefaults to the new swiftbuild backend, which fails on Command Line Tools setups before compiling anything ("Could not initialize build system … Unknown error parsing property list"). So the build always failed, quietly.build-vzhelper.tsnow retries a failedswift buildwith--build-system native, which still builds this package (SwiftPM warns that it's deprecated). Toolchains whose default works never take the retry.packages/codev-sandboxis fork-only, so noDIVERGENCES.mdrow.Not covered: release packaging's
--universalbuild has a second CLT 27 problem. The x86_64 slice fails to link because the toolchain's Swift compatibility libraries are arm64-only. That needs a decision about dropping the back-compat shims for Intel macOS 12.0–12.2 and is left out here; dev builds are host-arch only.Test plan
spawnon a missing helper:start()rejects with the "not installed" message. Without the fix it fails with "Unhandled error … ENOENT".bun testinpackages/codev-sandbox(191 pass)bun typecheckinpackages/codev-sandboxandpackages/desktopbun script/build-vzhelper.tson Swift 6.4 / CLT 27: falls back to the native build system, producesdist/codev-vmmsigned withcom.apple.security.virtualization; an up-to-date rerun takes ~1.5 sbun dev:desktopon the reporting machine: no crash dialog, and sandboxes start with the freshly built helper🤖 Generated with Claude Code