›_ Codex Issues
Codex Issues / #5914

Running `codex exec` against the configured MCP server on macOS causes an immediate panic in the `system-configuration` crate

Resolved 💬 5 comments Opened Oct 29, 2025 by Czaruno Closed Jan 17, 2026
💡 Likely answer: A maintainer (tekumara, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.50.0

What subscription do you have?

Codex Pro (self-service workspace)

Which model were you using?

gpt-5-codex (default from ~/.codex/config.toml)

What platform is your computer?

Darwin arm64 arm macOS 15.5 (24F74)

What issue are you seeing?

Running codex exec against the configured software-factory MCP server on macOS causes an immediate panic in the system-configuration crate:

RUST_BACKTRACE=full codex exec "Call the software-factory MCP server to list available tools and print the tool metadata."

thread 'tokio-runtime-worker' panicked at /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/system-configuration-0.6.1/src/dynamic_store.rs:154:1:
Attempted to create a NULL object.
stack backtrace:
   0:        0x10610c704 - __mh_execute_header
   1:        0x105d0ca20 - __mh_execute_header
   2:        0x10610bbd0 - __mh_execute_header
   3:        0x10610c5c4 - __mh_execute_header
   4:        0x10610c360 - __mh_execute_header
   5:        0x10610ba24 - __mh_execute_header
   6:        0x10610b48c - __mh_execute_header
   7:        0x10610b45c - __mh_execute_header
   8:        0x106334770 - __mh_execute_header
   9:        0x1063199a4 - __mh_execute_header
  10:        0x106319630 - __mh_execute_header
  11:        0x105f863a8 - __mh_execute_header
  12:        0x1050bb370 - __mh_execute_header
  13:        0x104f49df0 - __mh_execute_header
  14:        0x105264f5c - __mh_execute_header
  15:        0x10618a05c - __mh_execute_header
  16:        0x10618fd18 - __mh_execute_header
  17:        0x10616f15c - __mh_execute_header
  18:        0x106174fbc - __mh_execute_header
  19:        0x10613d63c - __mh_execute_header
  20:        0x199ef6c0c - __pthread_cond_wait

thread 'main' panicked at /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/system-configuration-0.6.1/src/dynamic_store.rs:154:1:
Attempted to create a NULL object.
stack backtrace:
   0:        0x10610c704 - __mh_execute_header
   1:        0x105d0ca20 - __mh_execute_header
   2:        0x10610bbd0 - __mh_execute_header
   3:        0x10610c5c4 - __mh_execute_header
   4:        0x10610c360 - __mh_execute_header
   5:        0x10610ba24 - __mh_execute_header
   6:        0x10610b48c - __mh_execute_header
   7:        0x10610b45c - __mh_execute_header
   8:        0x106334770 - __mh_execute_header
   9:        0x1063199a4 - __mh_execute_header
  10:        0x106319630 - __mh_execute_header
  11:        0x105f863a8 - __mh_execute_header
  12:        0x1050b158c - __mh_execute_header
  13:        0x104f4cdf8 - __mh_execute_header
  14:        0x104f4b028 - __mh_execute_header
  15:        0x105368a88 - __mh_execute_header
  16:        0x104f6fdf4 - __mh_execute_header
  17:        0x104f6c998 - __mh_execute_header
  18:        0x104f64dcc - __mh_execute_header
  19:        0x104f3c5ec - __mh_execute_header
  20:        0x104f8a188 - __mh_execute_header
  21:        0x1053ab1c4 - __mh_execute_header
  22:        0x1052b0994 - __mh_execute_header
  23:        0x1053a6998 - __mh_execute_header
  24:        0x1050ea0c4 - __mh_execute_header
  25:        0x1053c11f4 - __mh_execute_header

What steps can reproduce the bug?

Steps to reproduce

  1. Configure the MCP server in ~/.codex/config.toml (trimmed):

``toml
[mcp_servers."software-factory"]
url = "https://api.factory.8090.dev/mcp/"
headers = { "X-API-Key" = "<redacted>", "Accept" = "application/json, text/event-stream" }
``

  1. Launch Codex CLI 0.50.0 and run

RUST_BACKTRACE=full codex exec "Call the software-factory MCP server to list available tools and print the tool metadata."

  1. The CLI panics before emitting any MCP output.

What is the expected behavior?

Expected behavior

Codex CLI should call the MCP server, stream the tools/list response, and print the tool metadata instead of aborting.

Additional information

Additional information

  • The MCP endpoint itself is healthy: invoking tools/list via curl succeeds and returns the three expected tools.
  • The panic happens in system-configuration-0.6.1 while creating the macOS dynamic store; it looks like the CLI's network reachability watcher is constructing a NULL SCDynamicStore.
  • uname -mps output: Darwin arm64 arm.

View original on GitHub ↗

5 Comments

goncalossilva · 9 months ago

One can also reproduce this by attempting to run Codex inside sandbox-runtime:

$ RUST_BACKTRACE=full srt codex
Running: codex
WARNING: proceeding, even though we could not update PATH: No such file or directory (os error 2) at path "/tmp/claude/.tmphLlsdK"

thread 'main' panicked at /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/system-configuration-0.6.1/src/dynamic_store.rs:154:1:
Attempted to create a NULL object.
stack backtrace:
   0:        0x103e12cb8 - __mh_execute_header
   1:        0x1039f1eb0 - __mh_execute_header
   2:        0x103e12184 - __mh_execute_header
   3:        0x103e12b78 - __mh_execute_header
   4:        0x103e12914 - __mh_execute_header
   5:        0x103e11fd8 - __mh_execute_header
   6:        0x103e11a40 - __mh_execute_header
   7:        0x103e11a10 - __mh_execute_header
   8:        0x10403de2c - __mh_execute_header
   9:        0x104022854 - __mh_execute_header
  10:        0x1040224e0 - __mh_execute_header
  11:        0x103c8d96c - __mh_execute_header
  12:        0x103139230 - __mh_execute_header
  13:        0x103138250 - __mh_execute_header
  14:        0x102a27618 - __mh_execute_header
  15:        0x102e80020 - __mh_execute_header
  16:        0x102e9c5b0 - __mh_execute_header
  17:        0x102d9969c - __mh_execute_header
  18:        0x102e97c98 - __mh_execute_header
  19:        0x102bcd614 - __mh_execute_header
  20:        0x102eb2fbc - __mh_execute_header
tekumara contributor · 9 months ago

Same problem running taplo:

codex debug seatbelt taplo lint pyproject.toml

thread 'main' panicked at /Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/index.crates.io-1949cf8c6b5b557f/system-configuration-0.5.1/src/dynamic_store.rs:154:1:
Attempted to create a NULL object.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I think the seatbelt policy needs:

(allow mach-lookup
  (global-name "com.apple.SystemConfiguration.configd")
)

see https://github.com/anthropic-experimental/sandbox-runtime/issues/30#issuecomment-3501934500

tekumara contributor · 9 months ago

I've believe this has been addressed here and shipped in 0.56.0 when using

[sandbox_workspace_write]
network_access = true
goncalossilva · 9 months ago

I'm still seeing this on 0.57.0, with or without:

[sandbox_workspace_write]
network_access = true

In ~/.codex/config.toml.

etraut-openai contributor · 7 months ago

Closing out old bugs.