All dev-channel macOS binaries crash at startup: hardened-runtime signature has no entitlements (Bun: "Ran out of executable memory")

[bakua]

Summary

Every current dev-channel macOS arm64 binary — CLI v0.2.10-dev.83 and server v0.2.10-dev.76 — is Developer-ID signed and notarized with the hardened runtime flag but an empty entitlements set. Bun-compiled binaries need com.apple.security.cs.allow-jit to allocate JIT memory under the hardened runtime, so every one of them dies immediately at startup with:

Ran out of executable memory while allocating 128 bytes.

(SIGTRAP / signal 5.)

This makes the entire dev channel unusable on macOS, which also blocks the remediation for #181 — the macOS installer fixes are only on dev, but no dev binary can execute on macOS.

Older artifacts from before the signing/notarization pipeline (server v0.2.0, CLI 0.2.1-preview.1775503793) execute fine on the same machine, so this is a regression that coincides with the new release-signing step (the schemaVersion: 2 manifests that carry signingIdentity / notarization fields). Notarization reports Accepted — notarization doesn't test execution, so nothing in the pipeline catches this.

Repro

CLI (macOS arm64):

HAPPIER_CHANNEL=publicdev curl -fsSL https://happier.dev/install | bash

Download, checksum, and minisign all verify; then the installer's own invocation of the new binary prints Ran out of executable memory while allocating 128 bytes. and the install aborts.

Server, via the relay runner:

npx --yes --package @happier-dev/relay-server happier-server --channel dev

Fetches and extracts happier-server-v0.2.10-dev.76-darwin-arm64 into the cache, then the spawned binary crashes with the same message (terminated by signal 5).

happier relay host install --mode user --channel dev fails the same way (server crash-loops in server.err.log with the same message).

Evidence: the signature

$ codesign -dvv --entitlements - happier-server   # v0.2.10-dev.76, sha256 matches darwin-arm64.server.json
Identifier=happier-server
Format=Mach-O thin (arm64)
CodeDirectory v=20500 size=585626 flags=0x10000(runtime) hashes=18295+2 location=embedded
Authority=Developer ID Application: Leeroy Brun (L86V3EF623)
TeamIdentifier=L86V3EF623
Runtime Version=15.2.0

…and the --entitlements - output is empty — no entitlements blob at all. flags=0x10000(runtime) (hardened runtime) without com.apple.security.cs.allow-jit means mmap(MAP_JIT) is denied, and JavaScriptCore's executable allocator fails on its first allocation — which is exactly the observed error.

Confirming the mechanism

Disabling the JIT via JSC options makes the crash disappear, which pins the cause on executable-memory allocation rather than anything in the app code:

• Server: BUN_JSC_useJIT=0 npx --yes --package @happier-dev/relay-server happier-server --channel dev → boots fully, /v1/version returns {"ok":true}, serves normally. (Usable as a temporary self-host workaround, at interpreter-speed JS.)
• CLI: the same env gets past the memory error but then dies with ReferenceError: SharedArrayBuffer is not defined (Bun v1.3.5) — JSC drops SharedArrayBuffer in no-JIT mode and the CLI uses it at startup — so there is no env-level workaround for the CLI. It needs the entitlement.

Suggested fix

Sign the Bun-compiled binaries (happier, happier-server, happier-server-migrate) with an entitlements plist containing at least:

<key>com.apple.security.cs.allow-jit</key><true/>

i.e. codesign ... --options runtime --entitlements entitlements.plist .... Bun's own docs on codesigning compiled executables under the hardened runtime document the required entitlement set (allow-jit, and depending on Bun version allow-unsigned-executable-memory). A cheap regression guard: have CI run each signed+notarized darwin artifact once (--version / /v1/version) on a macOS runner before publishing the release.

Environment

• macOS 26 (Darwin 25.6.0), Apple Silicon (M4)
• CLI v0.2.10-dev.83, server v0.2.10-dev.76 (both darwin-arm64, hashes verified against the release manifests)
• Bun runtime in the binaries: v1.3.5
• Older, pre-pipeline binaries (server v0.2.0, CLI 0.2.1-preview) run fine on the same machine

[happier-bot]

Implemented in source. Thanks for tracking this down - the BUN_JSC_forceJIT=0 comparison and entitlement inspection were the key discriminators that confirmed hardened runtime was denying Bun's JIT executable memory.

The shared standalone notarization path was signing the top-level Bun executables with hardened runtime while preserving their original empty entitlements. The correction now applies only com.apple.security.cs.allow-jit to the product executables used by the CLI, HStack, server, and server migration payloads. Nested tools and native add-ons remain unchanged.

Signature verification now explicitly requires that entitlement both immediately after signing and when validating the repackaged release evidence. This keeps the fix in the canonical signer and avoids broader executable-memory exceptions.

The change landed on dev in a0b85f5fdd and was carried into v0.3 in 844090693e. The release contract suites pass; the remaining validation is the next signed and notarized dev artifact.

Once this reaches stage:dev, could you retry the CLI and server without BUN_JSC_forceJIT=0 and confirm that both start normally?

cc: @leeroybrun