codex - 💡(How to fix) Fix File Access Permission Selector Stuck Loading

no-active-thread-019e70e7-04d8-7212-8f52-0c90ef5db11c

Summary The file access permission selector button is permanently stuck in a loading/spinner state across ALL conversations. This completely blocks the chat input — no messages can be sent, no commands can be issued, no work can be done. The entire application is a $200/month paperweight right now.

My subscription is active. My disk has 13GB free. macOS permissions are correct. Code signing is valid. There is nothing wrong on my end. Through deep code analysis of the asar bundle, I've traced the issue to a deadlock in the permission mode initialization pipeline.

Impact I cannot overstate how destructive this bug is. This is not a minor inconvenience — this is a total application failure.

I have critical production projects that are blocked from launching because Codex is completely non-functional. Every hour this persists is real money lost and real deadlines missed.

I've spent hours diagnosing this myself — extracting the asar bundle, decompiling the minified JS, tracing the permission mode state machine, analyzing Statsig feature flag initialization, reading SQLite logs, and inspecting IPC handlers — because the application gave me ZERO diagnostic information. Just a silent infinite spinner.

Reproduction Open Codex (any workspace, any project) Look at the file access permission selector (the dropdown/button near the chat input) It shows a loading spinner indefinitely Try to type and send any message → impossible, input is blocked Switch to a different conversation → same problem Create a new conversation → same problem Restart Codex → same problem persists This affects 100% of conversations, not just one.

Environment & Diagnostic Details Config (~/.codex/config.toml) toml

sandbox_mode = "danger-full-access" approval_policy = "never" approvals_reviewer = "user" The most permissive configuration possible — yet the permission selector can't even finish loading.

Entitlements (verified via codesign -d --entitlements)

com.apple.security.app-sandbox = false ← NOT sandboxed com.apple.security.files.user-selected.read-write = true com.apple.security.network.client = true com.apple.security.automation.apple-events = true com.apple.security.cs.allow-jit = true com.apple.security.cs.allow-unsigned-executable-memory = true All correct. No macOS-level permission issue.

Code Signature

codesign --verify --deep --strict: PASSED Notarization: stapled Authority: Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2) Hardened Runtime: enabled System State Disk: 13GB available (NOT full) No quarantine flags (xattr clean) No sandbox violations in system logs No TCC denials in unified log All Codex processes running normally (main, GPU, renderer, app-server instances) SIP: enabled Gatekeeper: enabled Running Processes (at time of failure)

/Applications/Codex.app/Contents/MacOS/Codex ← main process /Applications/Codex.app/Contents/Resources/codex app-server ← primary app-server /Applications/Codex.app/Contents/Resources/codex app-server --listen stdio:// ← multiple instances /Applications/Codex.app/Contents/Frameworks/Codex Helper (Renderer) ← renderer /Applications/Codex.app/Contents/Frameworks/Codex Helper (GPU) ← GPU process Multiple node_repl and SkyComputerUseClient instances Everything appears to be running — yet the UI is completely stuck.

Large Data Files (potential contributors)

644 MB ~/.codex/logs_2.sqlite 91 MB ~/.codex/logs_2.sqlite-wal 5.4 MB ~/.codex/state_5.sqlite 4.0 MB ~/.codex/state_5.sqlite-wal 66 KB ~/.codex/.codex-global-state.json The logs_2.sqlite is 735 MB combined. If any startup or permission-loading logic queries this database synchronously, this could absolutely cause the loading hang.

What I've Already Tried ✅ Verified all macOS permissions (entitlements, code signing, notarization, TCC) ✅ Checked disk space (13GB free — not the issue) ✅ Restarted Codex ✅ Verified config.toml is set to maximum permissions ✅ Checked system logs for sandbox violations (none) ✅ Confirmed no quarantine flags ✅ Tried multiple workspaces and conversations ✅ Cleaned temp files Root Cause (from code analysis of the asar bundle) Through decompilation and analysis of the minified source code, I've traced the exact blocking chain:

1. Submit button is blocked by isAgentModePending In composer-EYkAbDY0.js, the submit logic calls hv() which computes:

javascript

disableSubmitForPendingPermissionsMode: e.isAgentModePending || (e.agentMode !== 'read-only' && e.isWindowsSandboxRequirementPending && !e.isWindowsSandboxSetupPending) When isAgentModePending is true, the entire chat input is blocked.

1. isAgentModePending comes from use-permissions-mode-BBZBxA7Q.js The B() (exported as usePermissionsMode) function computes:

javascript

let Z = B == null && ae == null && (h || b.isConfigDataPending); // Z becomes isAgentModePending So if isConfigDataPending is true, the mode is stuck pending.

1. isConfigDataPending comes from ne() function The ne() function computes:

javascript

let N = h || D || w || M; // Where: // D = isPending from requirements query (IPC: get-config-requirements-for-host) // w = isPending from effective config query
// M = j && n(k ?? undefined) !== false && g === undefined // g = statsig_default_enable_features (from shared object store) If ANY of these remain pending, the entire permission selector stays in loading state forever.

1. The statsig_default_enable_features dependency When g === undefined (Statsig feature flags not yet loaded), AND the config requirements suggest guardian mode is available (j is true), then M stays true → isConfigDataPending stays true → isAgentModePending stays true → submit is blocked.

This creates a hard dependency on Statsig initialization for the permission selector. If Statsig fails to initialize (network issues, API changes, rate limiting, corrupted cache), the entire application becomes unusable.

1. Observed state in ~/.codex/.codex-global-state.json json

"codexCloudAccess": "enabled_needs_setup" "agent-mode-by-host-id": { "local": "full-access" } The codexCloudAccess: "enabled_needs_setup" state may also be contributing to the loading loop.

Why This Is Unacceptable The permission selector blocks ALL chat input. A UI component that displays a mode dropdown should NEVER be able to make the entire application unusable. No error, no fallback, no timeout. If Statsig or the backend config query fails, the app should fall back to config.toml settings (which are danger-full-access + approval_policy = never). Zero diagnostic information. No console error, no log entry, no UI message. Just a silent spinner. config.toml has sandbox_mode = "danger-full-access" and approval_policy = "never" — the local configuration is correct and should be usable as a fallback. I wasted an entire day reverse-engineering your minified JavaScript to find this. A single error message or timeout would have prevented all of this. What I Need Never let the permission selector block the entire chat input. If permission state can't be resolved, show an error inline or use a default — don't freeze the entire application. Add a timeout/fallback for isConfigDataPending. If the config requirements query or Statsig initialization doesn't complete within N seconds, fall back to config.toml settings and show a warning. Show a clear error when the permission selector can't load. A toast, a banner, anything — not a silent infinite spinner. Add better diagnostic logging. When isConfigDataPending remains true for more than 10 seconds, log which specific sub-condition is stuck (Statsig? Config query? Requirements query?). Make the codexCloudAccess: "enabled_needs_setup" state actionable. If setup is needed, show a setup flow. Don't just silently block everything. Closing I chose Codex as my primary development tool and have invested significantly in building my workflow around it. Having it completely break with no workaround and no error message — just a silent infinite spinner — is unacceptable for a product at this price point. I expect this to be treated as a P0 blocker and resolved urgently.

Diagnostic data collected at 2026-05-29T07:00 CST (UTC+8)