v0.8.1 darwin-arm64 binary aborts with `dyld: unknown imports format` on macOS 26.5.1

[polyglotszeng]

[Bug]: v0.8.1 darwin-arm64 binary aborts with dyld: unknown imports format on macOS 26.5.1

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-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:

1. 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.
2. 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

1. Rebuild v0.8.2 with the latest stable Go (1.23+) on a host running macOS 26 Beta.
2. CI smoke test: add a "run --version on darwin-arm64 macOS 26" job before publishing the release asset.
3. 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.
4. 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).

[github-actions]

Thanks for raising this! It looks like a duplicate of an existing issue — the canonical one is linked above. Continuing the discussion there keeps everything in one place. We leave this open for visibility; a maintainer will close it once it's fully covered.

[DeusData]

Thanks for the report. I’ve marked this as a duplicate and am keeping #630 as the canonical structured report for the macOS 26 dyld: unknown imports format release-binary failure.

[DeusData]

Closing as a strict duplicate of #630.

#630 is the canonical, best-described report for the v0.8.1 darwin-arm64 dyld: unknown imports format failure on macOS 26.5.1. The title, environment, reproduction, binary diagnostics, and failure mode match exactly, so keeping the investigation and status in #630.