Rust panic in system-configuration crate when SCDynamicStoreCreate returns NULL (sandboxed environments)

Bug Description

codex exec crashes with a Rust panic before executing any command when run inside a sandboxed environment (e.g., Claude Code's sandbox) that blocks access to macOS's configd daemon:

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

Environment

• macOS Darwin 25.3.0 (arm64)
• codex-cli 0.116.0
• Binary: ~/.npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/codex/codex

Reproduction

Run codex exec in any environment that restricts unix socket access to configd:

# Works fine (no network initialization):
codex --version

# Crashes:
codex exec --full-auto "echo hello"

Root Cause

1. codex exec initializes its Rust HTTP client
2. The HTTP client (likely reqwest via hickory-dns) uses the system-configuration crate (v0.6.1) to read macOS DNS resolver config
3. SCDynamicStoreCreate connects to configd via unix socket
4. In sandboxed environments, the unix socket connection is blocked → SCDynamicStoreCreate returns NULL
5. The system-configuration crate panics on NULL instead of handling it gracefully

Expected Behavior

SCDynamicStoreCreate returning NULL should be handled gracefully — fall back to /etc/resolv.conf or system defaults rather than panicking. This is a valid runtime condition in sandboxed environments.

Workaround

Disabling the sandbox before invoking codex exec avoids the crash. But the underlying issue is that the NULL return from SCDynamicStoreCreate is not handled.

Notes

• codex --version works because it doesn't initialize the HTTP client
• RUST_BACKTRACE=full provides no useful info — symbols are stripped in the release binary
• The binary has no codesign entitlements — this is not an entitlements issue
• DNS_RESOLVER=system env var has no effect