`codex exec --sandbox workspace-write` panics in `system-configuration` / `reqwest` / `opentelemetry-otlp` before prompt execution

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

Title: codex exec --sandbox workspace-write panics in system-configuration / reqwest / opentelemetry-otlp before prompt execution

Summary

Running codex exec non-interactively with a writable sandbox crashes before the mission prompt can create any artifacts.

The repro command was:

codex exec --sandbox workspace-write \
  --output-last-message /Users/mac/Desktop/Workspace/personal/codexkit/.tmp/next16-supabase-mission-review/codex-mission-review.txt \
  '/prompts:mission integrate supabase with nextjs 16'

Instead of running the prompt to completion, the Codex CLI process panics in:

  • system-configuration
  • reqwest
  • opentelemetry-otlp

This happened before .missions/ or .beads/ could be created, so it blocks end-to-end prompt-path testing even though the repo-local mission runtime works when invoked directly.

Environment

  • Codex CLI: OpenAI Codex v0.118.0 (research preview)
  • OS: macOS (Apple Silicon)
  • Working repo: /Users/mac/Desktop/Workspace/personal/codexkit/.tmp/next16-supabase-mission-review
  • Sandbox mode: workspace-write
  • Approval mode: never

Reproduction

  1. Prepare a writable repo with a valid mission prompt setup.
  2. Run:
codex exec --sandbox workspace-write \
  --output-last-message /Users/mac/Desktop/Workspace/personal/codexkit/.tmp/next16-supabase-mission-review/codex-mission-review.txt \
  '/prompts:mission integrate supabase with nextjs 16'

Expected

  • codex exec starts normally
  • the mission prompt runs
  • if the prompt succeeds, it creates .missions/<id>/mission.json and .beads/artifacts/...
  • if the prompt fails logically, it should still return a normal model/tool failure rather than crash the runtime

Actual

The CLI panics with output including:

thread 'reqwest-internal-sync-runtime' ... panicked at ... system-configuration ...
Attempted to create a NULL object.

thread '<unnamed>' ... panicked at ... reqwest ...
event loop thread panicked

thread 'main' ... panicked at ... opentelemetry-otlp ...
called `Result::unwrap()` on an `Err` value: Any { .. }
Could not create otel exporter: panicked during initialization

The run then shows the standard Codex header, but no mission artifacts are created.

Artifact Check After Failure

After the crash:

  • .missions/ did not exist in the target repo
  • .beads/artifacts/ did not exist in the target repo
  • the requested output-last-message file was empty

Why this looks like a Codex CLI bug

  • The panic occurs inside Codex runtime initialization, not mission logic.
  • The repo-local deterministic mission runtime works when invoked directly via shell script.
  • The writable prompt-path test is blocked by the CLI process dying before prompt execution can finish.

Impact

This blocks validation of prompt-based end-to-end workflows that rely on codex exec --sandbox workspace-write, even when the underlying repo scripts and orchestration flow are healthy.

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.

  • #16391
  • #15296
  • #15640
  • #15641

Powered by Codex Action

harshitagarwal2 · 29 days ago

I believe this is already fixed by #16670 and can be closed as fixed/a duplicate of #15640.

Root cause: v0.118.0 pinned hyper-util 0.1.19 and system-configuration 0.6.1. When an outer macOS sandbox denied access to com.apple.SystemConfiguration.configd, proxy discovery received a NULL SCDynamicStore handle and panicked. #16670 upgraded to hyper-util 0.1.20 and system-configuration 0.7.0, which safely handle that denial; the change first shipped in v0.119.0.

Verification on 2026-07-29 (macOS arm64):

  • Codex 0.146.0-alpha.3.1
  • launched under a Seatbelt profile denying the configd mach lookup
  • used a dummy localhost model provider to avoid an external model request
  • Codex passed telemetry/runtime initialization and reached /v1/models and /v1/responses requests
  • no system-configuration, reqwest-internal-sync-runtime, or opentelemetry-otlp panic occurred

The only errors were the expected connection refusals from the intentionally unreachable localhost endpoint. Would a maintainer please close this as fixed/duplicate?

etraut-openai contributor · 25 days ago