›_ Codex Issues
Codex Issues / #10482

`spacetime publish` panics in `system_configuration` when run from Codex tool context on macOS

Resolved 💬 4 comments Opened Feb 3, 2026 by coldpeteza Closed Aug 5, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

Version 260202.0859 (517)

What subscription do you have?

free

Which model were you using?

got-5.2-codex medium

What platform is your computer?

Darwin 25.2.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

Title
spacetime publish panics in system_configuration when run from Codex tool context on macOS

Summary
Running spacetime publish from the Codex app tool context on macOS panics with Attempted to create a NULL object in system_configuration::dynamic_store::SCDynamicStoreBuilder::build, while the same command works fine in a regular terminal.

Environment

  • OS: macOS
  • Command context: Codex app tool execution
  • Working directory: /Users/pziersch/code/spacetimedb-connector/my-spacetime-app
  • SpacetimeDB CLI: installed locally (same binary used successfully in normal terminal)

Repro Steps

  1. From Codex app tool context, run:

spacetime publish --project-path spacetimedb/ my-db-test

  1. Observe panic.

Expected
Module publishes successfully (same as running in a normal terminal).

Actual
Panic with Attempted to create a NULL object.

Backtrace (top) 

system_configuration::dynamic_store::SCDynamicStoreBuilder<T>::build
hyper_util::client::proxy::matcher::mac::with_system
reqwest::async_impl::client::ClientBuilder::build
spacetimedb_cli::subcommands::publish::exec
spacetimedb_cli::main

Notes

  • Clearing proxy env vars (HTTP_PROXY, HTTPS_PROXY, NO_PROXY) did not help.
  • Full backtrace available (included below if needed).
  • Suggest investigating environment/entitlements differences or proxy detection in reqwest/system_configuration when run from tool context.

What steps can reproduce the bug?

Running spacetime publish from the Codex app tool context on macOS panics with Attempted to create a NULL object in system_configuration::dynamic_store::SCDynamicStoreBuilder::build, while the same command works fine in a regular terminal.

What is the expected behavior?

Expected
Module publishes successfully (same as running in a normal terminal).

Actual
Panic with Attempted to create a NULL object.

Additional information

_No response_

View original on GitHub ↗

4 Comments

etraut-openai contributor · 6 months ago

Codex isn't panicking, correct? If I understand you correctly, one of the tools that the agent is calling is panicking when it's run within the Codex sandbox. It's probably not correctly handling an error condition that arises from the sandbox policy. You will probably need to work with the maintainers of the tool to get that fixed.

corrylc · 6 months ago

This may be related to the panic seen in uv, as the library and error are pretty much identical.

Which means spacetime may just need to update the system_configuration library, as uv did.

Ashutosh0x contributor · 6 months ago

I've updated the Seatbelt policy to allow access to SystemConfiguration and mDNS services. This should fix the panic in spacetime publish and the DNS resolution errors. Give it a shot on the latest build.

Hebilicious · 6 months ago

I'm having the same issue with codex-cli 0.101.0 and the latest codex app as well, for similar binaries https://moonrepo.dev/moon and https://moonrepo.dev/proto (https://github.com/moonrepo).
I've asked codex to debug and this is the output 

• Root cause confirmed: this is a sandbox/runtime issue on my side, not your local Moon install.

  What I verified:

  - Inside default Codex sandbox:
      - moon query projects panics with system-configuration... Attempted to create a NULL object.
      - scutil --dns returns No DNS configuration available.
  - Outside sandbox (escalated run):
      - moon query projects works and lists all projects correctly.
      - scutil --dns returns normal resolver entries.

  Conclusion:

  - The Codex sandbox environment doesn’t expose macOS SystemConfiguration data (DNS/proxy store).
  - Moon/proto command paths that initialize HTTP/proxy detection hit that missing API and panic.
  - This is environment-specific to my restricted execution context.

@Ashutosh0x did you publish the fix ?