›_ Codex Issues
Codex Issues / #15640

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

Resolved 💬 3 comments Opened Mar 24, 2026 by yulonglin Closed Apr 3, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 5 months ago

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

  • #15296
  • #15297

Powered by Codex Action

BaseInfinity · 4 months ago

I dug into this and put together a focused fix branch with regression coverage:

What the branch does:

  • bumps hyper-util 0.1.19 -> 0.1.20
  • resolves system-configuration 0.6.1 -> 0.7.0
  • updates MODULE.bazel.lock
  • adds a macOS regression test that runs the production reqwest client-construction path under sandbox-exec with com.apple.SystemConfiguration.configd denied

Root cause chain:

reqwest system proxy support
-> hyper-util client-proxy-system
-> system-configuration
-> SCDynamicStoreCreateWithOptions()

When a seatbelt profile denies mach-lookup for com.apple.SystemConfiguration.configd, SCDynamicStoreCreateWithOptions() returns NULL.

  • system-configuration 0.6.1 wraps that NULL and panics
  • system-configuration 0.7.0 adds the missing null check and returns None
  • hyper-util 0.1.20 handles that safely and skips proxy detection instead of crashing

Independent repro I used against the installed codex-cli 0.118.0:

printf '(version 1) (allow default) (deny mach-lookup (global-name "com.apple.SystemConfiguration.configd"))' > /tmp/deny-configd.sb
sandbox-exec -f /tmp/deny-configd.sb codex exec -s danger-full-access "echo test"

Observed there:

  • panic in system-configuration-0.6.1/src/dynamic_store.rs:154
  • exit code 101

Verification on the branch:

  • the new seatbelted regression test passes
  • cargo test -p codex-client passes in full
  • broader codex-core integration coverage in my desktop-thread environment still had unrelated failures, so I did not claim that suite was clean

Because docs/contributing.md says external PRs are by invitation only, I have not tried to force an unsolicited PR through.

If this approach aligns with the intended fix, would the team like me to open an invited PR from the branch above?

etraut-openai contributor · 4 months ago

Thanks for the bug report. This will be addressed in the next release.