Linux arm64: bundled codex-linux-arm64 musl binary segfaults with SEGV_ACCERR (exit 139)

[kikuchy]

What version of Codex CLI is running?

codex-cli 0.114.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.12.47+rpt-rpi-v8 aarch64 unknown

What terminal emulator and version are you using (if applicable)?

No response

What issue are you seeing?

Codex crashes with a segmentation fault (exit 139) on Linux arm64 / aarch64.

I traced the failure with strace. The crash is not in the Node wrapper itself, but in the bundled native binary from @openai/codex-linux-arm64:

@openai/codex-linux-arm64/vendor/aarch64-unknown-linux-musl/codex/codex

A worker thread in that process receives:
• SIGSEGV
• si_code=SEGV_ACCERR

After that, the parent process detects the child crash and exits with SIGSEGV as well, so the shell reports exit 139.

This looks related to the recent Linux segfault issues, but this reproduction is specifically on Linux arm64 / Raspberry Pi with the bundled codex-linux-arm64 musl binary. It may be distinct from the Linux tmux segfault fix already shipped in 0.114.0.

What steps can reproduce the bug?

Uploaded thread: 019ce0d6-d867-7bd0-b939-d7f4dd2eb57d

I can reproduce the crash by running codex in a Git repository on Linux arm64.

Environment characteristics:
• Raspberry Pi
• Raspberry Pi OS Lite (Debian Trixie) arm64 / aarch64
• containerized environment by Incus
• codex-cli 0.114.0 installed via npm/mise
• Node installed via mise
• (Maybe) Try to read and write 4-5 text files, then cause segmentation fault

Observed result:
• Codex exits with code 139
• shell reports segmentation fault

What is the expected behavior?

Codex should run normally and should not crash with a segmentation fault.

Additional information

which codex:

/home/kikuchy/.local/share/mise/installs/node/25.2.1/bin/codex

Resolved script:

/home/kikuchy/.local/share/mise/installs/node/25.2.1/lib/node_modules/@openai/codex/bin/codex.js

Exit code after crash:

$ echo $?
139

strace shows the bundled native binary being executed:

219718 execve("/home/kikuchy/.local/share/mise/installs/node/25.2.1/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-arm64/vendor/aarch64-unknown-linux-musl/codex/codex", ["/home/kikuchy/.local/share/mise/i"...], 0xe213eb0 /* 21 vars */ <unfinished ...>

The crashing thread receives SIGSEGV with SEGV_ACCERR:

219721 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x6ba2fb0} ---

The parent process then observes the child crash and propagates it:

219711 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=219718, si_uid=1000, si_status=SIGSEGV, si_utime=468 /* 4.68 s */, si_stime=740 /* 7.40 s */} ---
219711 wait4(219718, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG, NULL) = 219718
219711 kill(219711, SIGSEGV)            = 0
219711 tgkill(219711, 219711, SIGSEGV)  = 0

I checked coredumpctl info codex, but no coredumps were recorded.

Possible related issues:
• #13842
• #13889

However, I did not find an existing public issue matching this exact combination:
• Linux arm64 / Raspberry Pi
• bundled @openai/codex-linux-arm64
• aarch64-unknown-linux-musl/codex/codex
• SEGV_ACCERR
• exit 139

I can test with a different Node or Codex-cli version as needed if that would help narrow this down.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• segfault on linux #13889
• Crashed (segmentation fault, exited 139) inside tmux on Linux, introduced after v0.110.0 #13842

Powered by Codex Action

[etraut-openai]

Thanks for the bug report. Do you suspect that this is a recent regression? Are you able to get it to work if you downgrade to an earlier version of Codex CLI? If so, which version is the first that breaks?

[kikuchy]

@etraut-openai Thanks for checking!

I’m not sure whether this is a recent regression, because I only started using Codex CLI on this machine with 0.114.0, so I don’t yet have a known-good older version on this environment.

I’m going to try downgrading and testing earlier versions to narrow it down. At the moment, I don’t know which version first introduced the problem.

If there are any specific versions you would especially like me to test first, please let me know. Otherwise, I’ll try a few older releases and report back with the results.

[kikuchy]

@etraut-openai I searched binary.
It looks like its start from 0.114.0

• 0.100.0 ... works
• 0.107.0 ... works
• 0.110.0 ... works
• 0.112.0 ... works
• 0.113.0 ... works
• 0.114.0 ... fault

[etraut-openai]

Thanks for doing that analysis! Very helpful. That makes it pretty clear that this is a regression.