codex exec panics on macOS when SCDynamicStoreCreate returns NULL (sandboxed environments)

Bug: codex exec panics on macOS when SCDynamicStoreCreate returns NULL

Environment

• macOS 15.4 (Darwin 25.3.0, arm64)
• codex-cli 0.116.0
• Apple Silicon (aarch64-apple-darwin)

Reproduction

codex exec --full-auto "echo hello"

Error

thread 'main' panicked at system-configuration-0.6.1/src/dynamic_store.rs:154:1:
Attempted to create a NULL object.

Root Cause

codex exec initializes its HTTP client which uses the system-configuration Rust crate (v0.6.1) to read macOS DNS resolver config via SCDynamicStoreCreate. When the calling process cannot connect to configd (e.g., running inside a sandboxed environment that restricts unix socket access), SCDynamicStoreCreate returns NULL, and the crate panics instead of handling it gracefully.

codex --version and codex --help work fine because they do not initialize the HTTP client.

Expected Behavior

Codex should handle SCDynamicStoreCreate returning NULL gracefully — fall back to /etc/resolv.conf or system defaults instead of panicking. This would allow codex to work in sandboxed environments (e.g., when invoked as a subprocess from Claude Code or other tools that apply macOS sandbox profiles).

Workaround

Running codex exec outside the sandbox works fine. The issue only occurs when the process is sandboxed.

Notes

• The panic originates in the system-configuration crate (v0.6.1), not in codex code directly
• Symbols are stripped in the release binary so backtrace shows only __mh_execute_header
• This may be fixable by upgrading the system-configuration crate or by catching the NULL before it panics