[macOS Desktop] Local commands repeatedly crash before exec in Network.framework pthread_atfork handler

What version of the Codex App are you using (From “About Codex” dialog)?

26.908.70816 (build 9275), bundled codex-cli 0.154.0-alpha.6.2

What subscription do you have?

ChatGPT Plus

What platform is your computer?

macOS 26.6.2 (Build 25G83), Apple Silicon arm64

What issue are you seeing?

Summary

After the ChatGPT/Codex Desktop app has been running for approximately
1–2 days, all local command executions begin failing immediately with
exit code 139 and no stdout or stderr.

Even a minimal command such as /bin/true fails.

Restarting the desktop app temporarily restores local command execution,
but the problem returns after another long-running session.

The ChatGPT UI and non-local tools continue to work while local command
execution is broken.

Environment

• Codex Desktop: 26.908.70816
• Build: 9275
• Bundled CLI: codex-cli 0.154.0-alpha.6.2
• macOS: 26.6.2
• macOS build: 25G83
• Architecture: Apple Silicon arm64

Steps to reproduce

1. Launch ChatGPT/Codex Desktop on macOS.
2. Keep the app running and use local Codex tasks normally for
   approximately 1–2 days.
3. Attempt to execute any local command.
4. The command exits immediately with code 139 and no output.
5. The behavior also reproduces with /bin/true, different shells,
   login: false, and with or without a working directory.
6. Restart ChatGPT/Codex Desktop.
7. Local command execution works again temporarily.

Expected behavior

Local commands should continue to execute normally during long-running
desktop sessions.

Actual behavior

Every newly created codex child process crashes during fork(),
before the requested command is executed.

The parent ChatGPT and codex processes remain alive, which is why the UI
and other non-local tools continue to work.

Crash details

The macOS crash report records:

• Exception: EXC_BAD_ACCESS
• Signal: SIGSEGV
• Subtype: KERN_INVALID_ADDRESS
• Termination: Segmentation fault: 11
• Faulting thread: 0

Relevant stack:

_os_log_preferences_refresh
os_log_type_enabled
NEFlowDirectorDestroy
nw_path_release_globals
nw_settings_child_has_forked
_pthread_atfork_child_handlers
fork
codex
tokio::runtime::scheduler::multi_thread::worker::run

### What steps can reproduce the bug?

[codex-fork-crashes.zip](https://github.com/user-attachments/files/32317025/codex-fork-crashes.zip)

### What is the expected behavior?

_No response_

### Additional information

_No response_

Begin with the macOS crash stack in the issue, following the tokio worker through fork and the pthread_atfork child handlers; inspect the attached codex-fork-crashes.zip alongside the listed environment. Done means newly created local commands, including /bin/true, continue to execute after a 1–2-day desktop session without exit 139 or empty output.