Description
On macOS, running codex login status inside Claude Code's sandbox causes a Rust panic in the system-configuration crate, which makes getCodexLoginStatus() report loggedIn: false even when the user has valid tokens in ~/.codex/auth.json.
Error
WARNING: proceeding, even though we could not update PATH: Operation not permitted (os error 1)
thread 'main' panicked at system-configuration-0.6.1/src/dynamic_store.rs:154:1:
Attempted to create a NULL object.
Root cause
The Codex CLI binary accesses macOS's SCDynamicStore API on every invocation to update the system PATH. When Claude Code's sandbox blocks this access, SCDynamicStoreCreate returns NULL and the Rust wrapper panics instead of handling the error gracefully.
codex --version shows the warning but still succeeds (the panic is non-fatal for this command)
codex login status triggers a full panic and exits non-zero
codex whoami also panics
Running the same commands outside the sandbox works correctly:
$ codex login status
Logged in using ChatGPT
Impact
/codex:setup reports loggedIn: false despite valid authentication
ensureCodexReady() throws "Codex CLI is not authenticated" before any review or task
- All
/codex:review and /codex:task commands are blocked
Workaround
Read ~/.codex/auth.json directly in getCodexLoginStatus() before falling back to the binary call. The file contains the same tokens that codex login status would check.
Environment
- macOS (Darwin 25.3.0, Apple Silicon)
- Codex CLI: 0.117.0
- codex-plugin-cc: 1.0.1
- Claude Code sandbox enabled
Related
Description
On macOS, running
codex login statusinside Claude Code's sandbox causes a Rust panic in thesystem-configurationcrate, which makesgetCodexLoginStatus()reportloggedIn: falseeven when the user has valid tokens in~/.codex/auth.json.Error
Root cause
The Codex CLI binary accesses macOS's
SCDynamicStoreAPI on every invocation to update the system PATH. When Claude Code's sandbox blocks this access,SCDynamicStoreCreatereturns NULL and the Rust wrapper panics instead of handling the error gracefully.codex --versionshows the warning but still succeeds (the panic is non-fatal for this command)codex login statustriggers a full panic and exits non-zerocodex whoamialso panicsRunning the same commands outside the sandbox works correctly:
Impact
/codex:setupreportsloggedIn: falsedespite valid authenticationensureCodexReady()throws "Codex CLI is not authenticated" before any review or task/codex:reviewand/codex:taskcommands are blockedWorkaround
Read
~/.codex/auth.jsondirectly ingetCodexLoginStatus()before falling back to the binary call. The file contains the same tokens thatcodex login statuswould check.Environment
Related
codex login statusreports "Not logged in" when using Azure model provider #21 (codex login statusfalse-negative with Azure provider)