Repository navigation
[Bug] v0.8.1 darwin-arm64 binary aborts with dyld: unknown imports format on macOS 26.5.1 #630
Description
Summary
The official codebase-memory-mcp v0.8.1 darwin-arm64 binary fails to load on macOS 26.5.1 (Tahoe Beta) with dyld: unknown imports format followed by Abort trap: 6. This affects every command, including --version and --help. The binary is otherwise valid (correct Mach-O arm64, fully static, properly signed, LC_BUILD_VERSION minos=14.0). This appears to be a deployment-side incompatibility between the binary's chained-fixup format and the newer dyld shipped with macOS 26.
Environment
| Field | Value |
|---|---|
| Hardware | Apple Silicon Mac (M-series, arm64) |
| OS | macOS 26.5.1 (Tahoe Beta) |
| Binary | codebase-memory-mcp v0.8.1 (release dated 2026-06-12) |
| Downloaded from | https://github.com/DeusData/codebase-memory-mcp/releases/download/v0.8.1/codebase-memory-mcp-darwin-arm64 (or equivalent asset name) |
| SHA256 | 381d13e7a191bba5a5456b2006b1ee81e53c931b182647c36ec00b4be3a1fbe6 |
| Size | 267,893,872 bytes (~256 MiB) |
| File type | Mach-O 64-bit executable arm64 |
Reproduction
# 1. Download the v0.8.1 darwin-arm64 release asset
curl -L -o codebase-memory-mcp \
https://github.com/DeusData/codebase-memory-mcp/releases/download/v0.8.1/codebase-memory-mcp-darwin-arm64
# 2. Make executable + clear quarantine + ad-hoc sign
chmod +x codebase-memory-mcp
xattr -cr codebase-memory-mcp
codesign --force --deep --sign - codebase-memory-mcp # ad-hoc
# 3. Try ANY command
./codebase-memory-mcp --version
./codebase-memory-mcp --help
./codebase-memory-mcp index /path/to/codebase
echo "" | ./codebase-memory-mcpExpected
codebase-memory-mcp version 0.8.1
Actual (all four commands)
dyld[12345]: unknown imports format
Abort trap: 6
Exit code 134 (SIGABRT) on every invocation, regardless of arguments.
What was verified
| Check | Command | Result |
|---|---|---|
| File type | file ./codebase-memory-mcp |
Mach-O 64-bit executable arm64 ✅ |
| External linkage | otool -L ./codebase-memory-mcp |
(empty — fully static) ✅ |
| Min OS version | otool -l ... | grep LC_BUILD_VERSION |
minos 14.0 (well below 26.5.1) ✅ |
| Code signature | codesign -dv |
valid (after re-sign) ✅ |
| Quarantine | xattr -l |
cleared ✅ |
| Architecture | lipo -info |
arm64 (correct for M-series) ✅ |
The binary passes every static / structural check. The abort happens during dynamic linking, before main() runs.
Root cause hypothesis
The binary contains LC_DYLD_CHAINED_FIXUPS (8456 bytes in the v0.8.1 sample). On macOS 14 Sonoma this format loaded without complaint. On macOS 26.5.1 (Tahoe Beta) the bundled dyld rejects the chained-fixup payload with the generic "unknown imports format" message and aborts. There are two likely culprits:
- Newer dyld stricter validation: macOS 26's dyld may have tightened what it accepts in chained-fixup payloads and now rejects an older format version that older dylds tolerated.
- Binary built against newer toolchain than dyld supports: Go's
internal/linkname+cmd/linkrework for chained fixups changed format between Go 1.22 and Go 1.23; if v0.8.1 was built with a Go toolchain newer than the macOS 26 SDK'sdyldwas tested against, the layout no longer round-trips.
Either way, the fix is the same: rebuild against the current macOS SDK + current Go toolchain, ideally with the binary smoke-tested on a macOS 26 (Tahoe) Beta host.
Suggested fix
- Rebuild v0.8.2 with the latest stable Go (1.23+) on a host running macOS 26 Beta.
- CI smoke test: add a "run
--versionon darwin-arm64 macOS 26" job before publishing the release asset. - Consider a fallback build flag — if the chained-fixup payload is the culprit,
-buildmode=piewith classic non-chained relocations may still load on older dylds. - Document supported macOS range in the release notes / README, so users on bleeding-edge macOS can plan ahead.
Workaround for users (until v0.8.2 lands)
- Use a Linux or older-macOS host to run cbm and have it serve MCP to your Mac over the network. The dyld abort is specific to darwin-arm64 macOS 26; the same binary works fine on macOS ≤ 15 and on Linux.
- Use an alternative MCP-compatible indexer with native Apple Silicon support. For Obsidian-vault-style corpora, the
graphifyskill (Python + tree-sitter) indexes ~1,500 notes in <1s with ~98 MB peak memory; for code corpora,mcp-server-tree-sitteris a pure-Python alternative.
Severity
High for anyone on macOS 26 Beta (which is most M-series users on the latest OS). The binary is the only published artifact for darwin-arm64, so affected users have no working local install path without manual workarounds.
Diagnostic data
$ sw_vers
ProductName: Mac OS X
ProductVersion: 26.5.1
BuildVersion: 25F77
$ uname -a
Darwin <host> 26.5.1 Darwin Kernel Version 26.5.1 ... arm64
$ file /tmp/bermanscan/codebase-memory-mcp
/tmp/bermanscan/codebase-memory-mcp: Mach-O 64-bit executable arm64
$ otool -l /tmp/bermanscan/codebase-memory-mcp | grep -A 4 LC_BUILD_VERSION
cmd LC_BUILD_VERSION
cmdsize 24
platform 1
minos 14.0
sdk 15.0(Replace <host> with hostname output if a maintainer needs to triage against a specific Beta build.)
Cross-references
- Similar reports may exist on the upstream issue tracker; please link duplicates here.
- macOS 26 Beta dyld changes: tracked in Apple's
dyldsource (no public release notes known at time of writing).
Activity
DeusData commentedon Jun 29, 2026
Thanks for the detailed binary diagnostics. I’ve triaged this under #390 and am keeping #630 as the canonical structured report; #629 is marked as the duplicate. Next step is release-build/linker-format investigation against macOS 26 dyld.
DeusData commentedon Aug 14, 2026
@polyglotszeng — thank you for the verification table. An empty
otool -L,LC_BUILD_VERSION minos 14.0, a valid ad-hoc signature and the SHA-256 of the exact release asset rule out everything on your side and point squarely at how we link the shipped binary.Every command aborting,
--versionincluded, also means there is no local workaround available to you: the binary simply does not run on that OS. That is the most literal possible version of "impossible to operate".Honest status: still open, and the investigation is on the release build's chained-fixup format against the newer dyld rather than anything in cbm's own logic. Tonight's v0.10.5 is being cut for exactly this class of issue. Sorry you have been waiting since June.
DeusData commentedon Sep 26, 2026
Thank you, @polyglotszeng, for the very complete verification table; it ruled out everything on your side!
We can no longer reproduce this. The current v0.11.0
codebase-memory-mcp-darwin-arm64release asset runs--versionfine on macOS 26.6 (25G72). The release binary has also changed a lot since v0.8.1: it's now fully stripped and about 40 MB instead of 256 MB.Could you try v0.11.0 and confirm that it starts? If it still aborts with
unknown imports format, please post the output ofotool -l codebase-memory-mcp | grep -A3 LC_DYLD_CHAINED_FIXUPSand your exactsw_vers.github-actions commentedon Sep 26, 2026
Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:
codebase-memory-mcp --versionyou're onOnce that's here we'll pick it straight back up. Heads-up: issues left
awaiting-reporterare automatically closed after a few weeks of silence, but a comment reopens the door anytime.github-actions commentedon Oct 18, 2026
This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked
stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.DeusData commentedon Oct 19, 2026
Thank you again for the binary diagnostics. Checking back on the September request: does a newer release start on your macOS build? If the dyld abort remains, the exact CBM asset/version and
sw_versare the useful comparison; I have no new confirmation for your machine to add.DeusData commentedon Oct 25, 2026
Thank you again for the report and your patience. Any existing newer-release startup result is welcome, with the exact asset/version and macOS build if the dyld abort remains.