What version of Codex CLI is running?

codex-cli 0.111.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.18.7-arch1-1 x86_64 unknown

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

Ghostty + tmux

What issue are you seeing?

codex --yolo resume intermittently crashes with a segmentation fault while running inside tmux on Linux.

This issue appears to have been introduced after v0.110.0. Versions at or below 0.110.0 worked correctly in the same environment.

Observed shell output:

zsh: segmentation fault (core dumped) RUST_LOG=codex_core=debug,codex_tui=debug,codex_rmcp_client=debug codex --yolo resume

Crashed at error 139

From coredumpctl info codex:

           PID: 3608715 (codex)
           UID: 1000 (qtnx)
           GID: 1000 (qtnx)
        Signal: 11 (SEGV)
     Timestamp: Sat 2026-03-07 14:04:13 +07 (30min ago)
  Command Line: /home/qtnx/.npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex/codex --yolo resume
    Executable: /home/qtnx/.npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex/codex
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/tmux-spawn-a14725d4-1978-4862-ab58-337e69626bb3.scope
          Unit: user@1000.service
     User Unit: tmux-spawn-a14725d4-1978-4862-ab58-337e69626bb3.scope
         Slice: user-1000.slice
     Owner UID: 1000 (qtnx)
       Boot ID: d70fd52a8f4b4e84a39af371365aee2b
    Machine ID: 51ce115006304b30ac3818f01e8c8929
      Hostname: codemc
       Storage: /var/lib/systemd/coredump/core.codex.1000.d70fd52a8f4b4e84a39af371365aee2b.3608715.1772867053000000.zst (present)
  Size on Disk: 20.4M
       Message: Process 3608715 (codex) of user 1000 dumped core.

                Module /home/qtnx/.npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex/codex without build-id.
                Stack trace of thread 3608733:
                #0  0x00007f3279eda6d5 n/a (/home/qtnx/.npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex/codex + 0x50da6d5)
                ELF object binary architecture: AMD x86-64

From GDB:

Program terminated with signal SIGSEGV, Segmentation fault.
Current thread: LWP 3608733

Relevant crash state:

(gdb) x/i $pc
=> 0x7f3279eda6d5: movb   $0x0,(%rdi,%r15,1)

(gdb) info registers
rdi            0x0
r15            0x2b
rip            0x7f3279eda6d5

This looks like a null-pointer write: the binary attempts to write a terminating '\0' byte into (%rdi + %r15) while rdi == 0x0.

Additional memory inspection:

(gdb) x/4gx $r12
0x7f327b471c70: 0x0000000000000000  0x0000000008010442
0x7f327b471c80: 0x0000000000000001  0x00007f325c8149b0

So *(r12) == 0 immediately before the write path that loads (%r12) into rdi.

Relevant disassembly around the crash:

0x00007f3279eda68d: mov    (%r12),%rdi
...
0x00007f3279eda6d5: movb   $0x0,(%rdi,%r15,1)

This suggests Codex is trying to null-terminate or update a text/buffer pointer that is unexpectedly null.

What steps can reproduce the bug?

The bug is intermittent and timing-dependent, so I do not currently have a 100% reliable reproduction.

Environment:

• Codex versions after v0.110.0 are affected
• Versions v0.110.0 and earlier worked correctly
• Linux Ormarchy / Arch-based Linux
• Kernel: Linux 6.18.7-arch1-1 x86_64
• running inside tmux
• shell: zsh

Command used:

codex --yolo resume
#or 
codex --yolo

Observed crashing thread:

Current thread: LWP 3608733

Best-effort reproduction steps:

1. Start a tmux session on Linux.

2. Run:

codex --yolo

3. Let it resume a previous session and continue running.
4. After a non-deterministic amount of time, Codex crashes with:

```text
zsh: segmentation fault (core dumped)

The time to failure is not fixed. It may happen after a few minutes, a few tens of minutes, or a few hours.

This is especially problematic for long-running sessions, because Codex may appear stable for a while and then crash unexpectedly mid-run.

I have not yet confirmed whether the trigger is specifically:

• resume state restoration
• TUI rendering/update activity
• or interaction with tmux / terminal handling

At the moment, the reproduction is intermittent rather than deterministic.

What is the expected behavior?

No crash on the long running session

Additional information

• This issue appears to be a regression introduced after v0.110.0.
• Versions v0.110.0 and earlier did not show this problem in the same environment.
• The crash appears to be in the native Codex binary, not in the shell.

• Crash signature:

  • SIGSEGV
  • null-pointer write
  • attempted write to offset 0x2b from a null base pointer

• Approximate binary crash offset:

  codex + 0x50da6d5
  

This is very inconvenient in practice because the crash does not happen immediately. Codex can run for some time and then die unexpectedly, which makes it unreliable for long-running sessions.