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
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-mcp
Expected
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/link rework 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's dyld was 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
--version on darwin-arm64 macOS 26" job before publishing the release asset.
- Consider a fallback build flag — if the chained-fixup payload is the culprit,
-buildmode=pie with 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
graphify skill (Python + tree-sitter) indexes ~1,500 notes in <1s with ~98 MB peak memory; for code corpora, mcp-server-tree-sitter is 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
dyld source (no public release notes known at time of writing).
Summary
The official
codebase-memory-mcpv0.8.1 darwin-arm64 binary fails to load on macOS 26.5.1 (Tahoe Beta) withdyld: unknown imports formatfollowed byAbort trap: 6. This affects every command, including--versionand--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
codebase-memory-mcpv0.8.1 (release dated 2026-06-12)381d13e7a191bba5a5456b2006b1ee81e53c931b182647c36ec00b4be3a1fbe6Mach-O 64-bit executable arm64Reproduction
Expected
Actual (all four commands)
Exit code
134(SIGABRT) on every invocation, regardless of arguments.What was verified
file ./codebase-memory-mcpMach-O 64-bit executable arm64✅otool -L ./codebase-memory-mcpotool -l ... | grep LC_BUILD_VERSIONminos 14.0(well below 26.5.1) ✅codesign -dvxattr -llipo -infoarm64(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 bundleddyldrejects the chained-fixup payload with the generic "unknown imports format" message and aborts. There are two likely culprits: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
--versionon darwin-arm64 macOS 26" job before publishing the release asset.-buildmode=piewith classic non-chained relocations may still load on older dylds.Workaround for users (until v0.8.2 lands)
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
(Replace
<host>withhostnameoutput if a maintainer needs to triage against a specific Beta build.)Cross-references
dyldsource (no public release notes known at time of writing).