MacOS intel x64 segmentation error

[arrrrny]

I just installed via curl, added to the path as well.

getting this:

~/D/raptorr ❯❯❯ codedb
[1] 29893 segmentation fault codedb
~/D/raptorr ❯❯❯ ✘ 139

[yanncabral]

I can reproduce this on a native Intel macOS machine with the current v0.2.5821 release asset, so the issue appears to persist after #509 / the v0.2.5821 release.

Environment:

• macOS 26.2 (25C56)
• MacBookPro16,1
• uname -m: x86_64
• asset: codedb-darwin-x86_64
• sha256: 46bc218b55c0ba2aa404998c7d74d6ee3f2b8022b7dea23c9b2f3cf71b22213b

Repro:

curl -fsSLO https://github.com/justrach/codedb/releases/download/v0.2.5821/codedb-darwin-x86_64
chmod +x codedb-darwin-x86_64
./codedb-darwin-x86_64 --help
echo $?
# 139

The same binary is also what npx -y codedeebee mcp installs via the npm package, so the MCP server exits immediately with Connection closed in clients that launch it through npx.

Crash report summary:

EXC_BAD_ACCESS / SIGSEGV
KERN_INVALID_ADDRESS at 0x0000000000000000
faultingThread: 0

One possibly useful data point: building the current main locally on the same machine works:

git clone https://github.com/justrach/codedb.git
cd codedb
zig build -Doptimize=ReleaseSafe
./zig-out/bin/codedb --help
# exit 0

So the source-level fix may be present on main, but the published v0.2.5821 codedb-darwin-x86_64 release asset still crashes on native Intel macOS.

[arrrrny]

@yanncabral agreed, latest binary still has it:

~/D/raptorr ❯❯❯ /Users/arrrrny/bin/codedb mcp
[1] 18173 segmentation fault /Users/arrrrny/bin/codedb mcp
~/D/raptorr ❯❯❯

[yanncabral]

Follow-up with a smaller repro and a likely direction for the fix.

I was able to reduce this outside of codedb: on native Intel macOS 26.2, a minimal Zig 0.16 x86_64-macos executable works unsigned, but segfaults after codesign.

Environment:

macOS 26.2 (25C56)
MacBookPro16,1
uname -m: x86_64
zig: 0.16.0 (/usr/local/Cellar/zig/0.16.0_1/bin/zig)

Minimal repro:

const std = @import("std");

pub fn main() void {
    const msg = "hello\n";
    _ = std.c.write(1, msg.ptr, msg.len);
}

Commands:

zig build-exe hello.zig -O ReleaseFast -target x86_64-macos -lc -femit-bin=hello
./hello
echo $?

codesign -f -s - hello
./hello
echo $?

Observed:

hello
0
hello
Segmentation fault: 11
139

So main does run and prints hello, but the signed Zig binary crashes during/after teardown. The crash report summary is:

EXC_BAD_ACCESS / SIGSEGV
KERN_INVALID_ADDRESS at 0x0000000000000001

I also tried these variants, and all signed Zig binaries still crashed:

-fllvm
-flibllvm
-fno-lld
-funwind-tables
-fno-unwind-tables
-target x86_64-macos.10.15
-target x86_64-macos.11.0
-target x86_64-macos.13.0
-target x86_64-macos.26.2

A C control binary signed with the same codesign -f -s - works on the same machine:

#include <stdio.h>
int main() { puts("hello-c"); return 0; }

cc hello.c -o hello-c
codesign -f -s - hello-c
./hello-c
# hello-c
# exit 0

This suggests the codedb crash is probably not project-specific and not just the !void entrypoint issue. It looks like a Zig 0.16 / Mach-O / x86_64 macOS 26 issue that is triggered once the binary is signed.

I also built codedb with a small release-pipeline workaround: skip codesigning only for the x86_64-macos slice. That produced an unsigned codedb binary that works on this machine:

zig build -Doptimize=ReleaseFast -Dtarget=x86_64-macos -Dcodesign-identity=-

codesign -dv --verbose=2 zig-out/bin/codedb
# code object is not signed at all

./zig-out/bin/codedb --help
# exit 0

./zig-out/bin/codedb --version
# exit 0
# codedb 0.2.5821

MCP smoke test also worked with that unsigned binary:

initialize -> result.protocolVersion = 2024-11-05
serverInfo.name = codedb
serverInfo.version = 0.2.5821
scan = ready
files = 377

The workaround patch I tested was basically:

• build.zig: make codesign-identity opt-in instead of defaulting to -, and skip signing when target.result.cpu.arch == .x86_64 on macOS.
• .github/workflows/release-binaries.yml: do not pass -Dcodesign-identity for the x86_64-macos matrix entry.

This is not ideal for macOS distribution, but it may be a practical short-term workaround for the npm/MCP path until the Zig/Mach-O signing issue is understood. I tried to file this minimal repro upstream at ziglang/zig, but interactions there are currently restricted to collaborators, so GitHub blocked both issue creation and commenting on the related Tahoe/x86_64 issue.