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

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.