Repository navigation
[macOS Apple Silicon] Compiled browse binary gets SIGKILL due to corrupt/linker-only code signature — setup should add ad-hoc codesign step #997
Description
Summary
On some Apple Silicon machines, the browse binary compiled by bun run build ships with a corrupt or linker-only code signature. macOS then kills every invocation with SIGKILL (zsh: killed, exit 137, 0 bytes output). The official ./setup never recovers — every re-run produces the same unrunnable binary.
The fix is two lines of codesign. I think it belongs in setup so Apple Silicon users don't have to diagnose this.
Environment
- macOS Darwin 25.4.0 (arm64)
- Apple Silicon
- Bun 1.3.12 (freshly installed per README requirement)
- gstack v0.16.4.0
- SIP enabled, Xcode Command Line Tools installed
- Fresh
git clone+./setupinstall (no vendoring)
Reproduction
# Official install path
git clone --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup
# Try to use browse
~/.claude/skills/gstack/browse/dist/browse status
# => zsh: killedIn Claude Code, every $B <cmd> call returns exit 137 with 0 bytes stdout/stderr. From a login shell terminal, zsh: killed.
Root cause
otool -l on the compiled binary shows a valid LC_CODE_SIGNATURE load command, but the signature block itself is corrupt/empty:
cmd LC_CODE_SIGNATURE
cmdsize 16
dataoff 61283152
codesign -dv reports code object is not signed at all. spctl --assess --verbose <binary> returns invalid or unsupported format for signature.
A naive codesign -s - -f <binary> also fails with "invalid or unsupported format for signature" because the existing (broken) signature block prevents re-signing. The only path that works is remove → re-sign:
codesign --remove-signature <binary>
codesign -s - -f <binary>After that, codesign -dv shows Signature=adhoc and the binary runs cleanly.
This matches the well-documented Apple Silicon policy: all executables must be properly signed (even ad-hoc), and linker-signed-only binaries get SIGKILL (Bun #7208, Go #42684, Bun docs on codesigning).
Why it hits some users and not others seems to depend on Bun version (1.3.x appears worse than 1.2.x at self-signing) and whether a prior corrupt signature exists from an earlier install.
Suggested fix
Add a macOS-only codesign step to setup after bun run build succeeds. Something like:
if [ "$(uname -s)" = "Darwin" ] && [ "$(uname -m)" = "arm64" ]; then
for bin in browse/dist/browse browse/dist/find-browse design/dist/design bin/gstack-global-discover; do
[ -x \"$bin\" ] || continue
codesign --remove-signature \"$bin\" 2>/dev/null || true
codesign -s - -f \"$bin\" 2>/dev/null || log \"warning: codesign failed for $bin\"
done
fiThis is idempotent (safe to re-run), costs <1s, and is what Bun's own docs recommend for distributed standalone executables. It would save Apple Silicon users from a dead-end debug session.
Workaround (for anyone hitting this now)
cd ~/.claude/skills/gstack
codesign --remove-signature browse/dist/browse
codesign -s - -f browse/dist/browse
# repeat for browse/dist/find-browse, design/dist/design, bin/gstack-global-discoverHappy to open a PR if helpful.
Related
- Watchdog kills browse server mid-workflow when invoked from skills #943 (watchdog kills server) — separate issue, patched independently
- Bun Issue #7208 (upstream)
Activity
BenoitDUHAMEL commentedon Apr 16, 2026
Confirming this is still reproducible on v0.18.0.1 + Bun 1.3.12, macOS Darwin 25.4.0 (arm64, M4 Pro). The
codesign --remove-signature+codesign -s - -fcombo works as described — binaries exit 0 with correct help output after the fix.Re-upgrading gstack removes the signatures again (since
./setuprebuilds the binaries), so users hit this every upgrade until the proposed setup step lands.Impact scope in v0.18.0.1: affects
browse/dist/browse,browse/dist/find-browse,design/dist/design, andbin/gstack-global-discover(all 4 Mach-O binaries produced by./setup). Any skill that shells out to these binaries (/browse,/canary,/design-review,/qa,/open-gstack-browser) fails silently with exit 137 and zero output — very hard to diagnose without checking$?.fix: ad-hoc codesign compiled binaries on Apple Silicon after build
codex + Apple Silicon hardening wave (v0.18.4.0) (garrytan#1056)
tsouthj commentedon May 8, 2026
Hi, just hit this on M4 MacBook Air (macOS latest). The codesign fix in the issue description doesn't work for find-browse and gstack-global-discover — both fail with a deeper error:
otool confirms the signature block is 488,914 bytes — clearly corrupt:
codesign -dv reports the binary is not signed at all despite the oversized block. Tried --remove-signature, --deep, --no-strict, rebuilding with bun run build — same result every time.
The two binaries that fail are find-browse and gstack-global-discover. browse and design sign fine with the ad-hoc fix.
Looks like bun is producing malformed Mach-O for these two specific binaries — the __LINKEDIT segment doesn't cover EOF which means no standard tool can process them. The codesign patch in setup will help for browse/design but won't fix these two. Might need a bun version pin or upstream bun bug report.
Happy to provide any additional diagnostics if helpful.
codex + Apple Silicon hardening wave (v0.18.4.0) (garrytan#1056)
codex + Apple Silicon hardening wave (v0.18.4.0) (garrytan#1056)
fix(smoke): tamper signed code, not the signature, to de-flake 10c
fix(smoke): assert codesign --verify rejects a tampered binary (10c)