app-server panics in sandboxed environments (SCDynamicStore NULL object)

Resolved 💬 3 comments Opened Apr 1, 2026 by shimakazuhito-prog Closed Apr 11, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Description

When running codex app-server inside a sandboxed environment (e.g., Claude Code sandbox on macOS), the process panics with the following error:

nice(5) failed: operation not permitted

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

Steps to Reproduce

Install Claude Code CLI and the Codex plugin
Run Claude Code inside Cursor IDE (or any sandboxed environment on macOS)
Invoke a Codex command (e.g., /codex:rescue) which triggers codex app-server

Expected Behavior

app-server should gracefully handle restricted system API access (e.g., SCDynamicStore, nice()) instead of panicking, or provide a clear error message indicating sandbox incompatibility.

Actual Behavior

The process panics due to SCDynamicStore returning NULL when system configuration access is restricted by the sandbox. The nice(5) call also fails with "operation not permitted".

Environment

codex-cli 0.117.0
macOS Darwin 25.3.0 (Apple Silicon)
Running inside Claude Code (Cursor IDE integration) with sandbox enabled
Node.js v22.17.1

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

#15640
#15641
#15296
#15297

Powered by Codex Action

Casey-Bates · 4 months ago

Same underlying bug on a different entry point.

Environment:

codex-cli 0.117.0
macOS Darwin 25.3.0 (Apple Silicon)
Claude Code 2.1.101 with sandbox enabled

Repro in the same outer sandbox:

codex exec "hi"
codex login status

Both panic with the same core failure:

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

I also see the related nice(5) failed: operation not permitted symptom.

Two useful additions to this thread:

This is not limited to app-server. It also affects codex exec and codex login status, so the blast radius is broader than a single subcommand.
The login status crash can create a false-negative auth diagnosis, because wrappers may conclude that subscription auth is missing when the command actually panicked before reporting status.

Local workaround that restores functionality inside the outer sandbox:

"network": {
  "allowMachLookup": [
    "com.apple.SystemConfiguration.configd",
    "com.apple.SystemConfiguration.DNSConfiguration",
    "com.apple.networkd"
  ],
  "allowLocalBinding": true
}

After regenerating the sandbox profile, codex exec and codex login status work again.

This looks consistent with the same macOS SystemConfiguration / proxy-detection initialization path discussed in related reports like #16908. From the outside, it still looks like Codex needs a structural fallback here rather than a fix tied to one entry point.

etraut-openai contributor · 4 months ago

This should be fixed in the latest release (0.119.0 or newer).