File Access Permission Selector Stuck Loading

Confirming this exact bug on macOS 26.527.60818 (bundled CLI/app-server 0.136.0-alpha.2, Apple Silicon, ChatGPT Plus), and adding a decisive test + mechanism that I think pins the root cause. Cross-refs: this is the same underlying failure as #21318 (MCP tool-discovery blocks the first turn) and the macOS cluster in #23979. @denixciao-sketch's decompilation here matches what I see end to end.

Symptom

Local-mode composer: the "Full access" permission selector sits in a perpetual loading/greyed state with a ⚠ icon; the send arrow spins forever and no local message can be sent; past local thread bodies render blank. Cloud mode works fine (it routes around the local app-server). Intermittent across identical builds — it worked previously with the exact same plugins/connectors installed, then stopped without any config change on my side.

Decisive test: it is NOT user config / connectors / plugins

I stripped the install to zero enabled plugins (every [plugins.*] enabled = false, config locked with chflags uchg so the desktop couldn't re-sync it) and relaunched. Send still spun. With nothing for the tool list to wait on, the composer is still blocked. So this is not fixable from the user side — it's in the app/app-server.

Mechanism (combining @denixciao-sketch's decompilation with app-server traces)

The composer's submit is gated on isConfigDataPending, which stays true while either:

1. list_all_tools hasn't completed — the app-server awaits tools from every MCP server on the startup/first-turn critical path (exactly #21318). Trace from logs_2.sqlite:

``
list_all_tools{mcp_server_count=5}: waiting for MCP server tools while building tool list
server_name=cloudflare-api has_cached_tool_info_snapshot=false startup_complete=true
`
has_cached_tool_info_snapshot is the key field: when a server has a cached snapshot the list returns instantly; when it's false, the app-server **waits for a live tools/list** — and a slow/unauthenticated/unreachable server (e.g. a connector whose OAuth token has since expired) hangs the whole list until the 31s timeout. **This explains the intermittency and "it worked before":** when the snapshots were warm / tokens valid, list_all_tools` returned fast; once a snapshot is cold and that server doesn't answer, it hangs.

1. Statsig hasn't loaded — statsig_default_enable_features === undefined with guardian mode available keeps isConfigDataPending true (@denixciao-sketch's chain). My ~/.codex/.codex-global-state.json has 0 statsig keys cached. Clearing the statsig plugin cache doesn't help (the value comes from the live SDK init, not a file). guardian_approval is server-pushed and ignores features.guardian_approval = false in config — so there is no user override for this branch either.

Even the hardcoded openai-bundled marketplace (browser/chrome/computer-use/latex) is registered via the node_repl sidecar on every launch regardless of plugin state, and its marketplace/add times out the same way:

bundled_plugins_marketplace_add_failed errorMessage="Timed out waiting for MCP response to marketplace/add"

node_repl itself is healthy — the fault is the app-server driving it

Driving the bundled node_repl directly over stdio, it answers initialize in <1s and executes a real js tool call (spawning its sandboxed Node kernel) in ~0.25s, returning valid results — both sandboxed and with --disable-sandbox. When the app-server spawns it, the process sits parked in tokio::park waiting for MCP traffic and is torn down ~3s later. So node_repl is fine; the app-server's sidecar/tool-discovery lifecycle is where it breaks.

The fix that would actually resolve this (same as @denixciao-sketch + #21318)

1. Never let MCP tool-discovery / Statsig block the composer. If isConfigDataPending can't resolve within N seconds, fall back to config.toml (mine is already sandbox_mode = "danger-full-access", approval_policy = "never") and let the user send. A silent infinite spinner with no error/timeout is the core defect.
2. Make optional MCP servers non-blocking (background tool discovery, incremental availability) per #21318 — only required = true servers should ever block startup/first turn.
3. Surface a diagnostic when isConfigDataPending stays true >10s (which sub-condition is stuck: requirements query / Statsig / a specific MCP server).

Happy to provide a RUST_LOG=trace app-server log slice from a failing launch, the zero-plugin-locked-config repro, the lsof/sample of the parked node_repl, or the node_repl stdio handshake repro. Also tracked via OpenAI support case 09438125.

Update: still fully broken on 26.601.20914 (build 3497) — the latest auto-update as of 2026-06-02 (macOS, Apple Silicon). I updated specifically to test whether this was addressed; it is not. The failure is byte-for-byte identical to 26.527.60818 and 26.519.31651 before it.

App-server log, one session on 26.601:

• marketplace/add → Timed out waiting for MCP response to marketplace/add (×14), bundled_plugins_marketplace_add_failed for marketplaceName=openai-bundled
• experimentalFeature/list → timed out (this is the call the composer's send path waits on: "Failed to check workspace dependencies feature for developer instructions")
• config/read, configRequirements/read, collaborationMode/list → succeed in 5–25ms only when plugins + the node_repl-dependent [features] (memories/chronicle/goals) are disabled (which makes the app log reconcile_skipped_features_unavailable and skip the hanging reconcile). With them enabled, config/read times out and the "Full access" chip spins forever.
• 0 messages dispatched all session — clicking send yields Unable to send message / Loading… and never reaches the backend, in both a new chat and an existing local thread.

Isolation done this round: from a completely clean slate — killed 27 lingering Codex processes including an orphaned openai-bundled/chrome extension-host parented to a dead app instance (these survive normal relaunch; the new launch immediately respawns one) — marketplace/add still times out. So it is not stale state or orphaned helpers. The bundled marketplace MCP handshake itself does not complete; the sidecar that should answer marketplace/add / experimentalFeature/list is gone seconds after launch, while node_repl is provably healthy when driven directly over stdio (initialize <1s, a real js tool call ~0.25s).

Net: the composer's send is hard-gated on MCP calls (experimentalFeature/list, marketplace/add) that depend on a bundled sidecar that never answers — with no timeout and no fallback, so it spins indefinitely. The CLI (codex exec/TUI) sends fine on the same build because it bypasses this path.

The fix, restated (matches @denixciao-sketch + #21318):

1. Never let bundled-marketplace marketplace/add or experimentalFeature/list block the composer/first turn — make optional MCP startup non-blocking and incremental.
2. Add a timeout + fallback to config.toml when isConfigDataPending can't resolve within N seconds, instead of an infinite silent spinner.
3. Surface which sub-condition is stuck after ~10s.

Also tracked via OpenAI support case 09438125. Happy to provide the full RUST_LOG=trace slice, the clean-slate repro, or the orphaned-extension-host ps capture.

Workaround found — and it pinpoints the exact culprit. On 26.601.20914 I traced the composer-send block to the bundled-marketplace handshake. The local app-server sidecar startup and marketplace/add hang specifically on the heavy bundled plugins (browser, chrome, computer-use); the lightweight latex plugin adds instantly. The runtime marketplace is (re)written on startup and on every window focus with pluginCount=4 ["browser","chrome","computer-use","latex"], and marketplace/add then times out (observed 14×/session) — which blocks thread/start, so the composer can never dispatch.

Disabling just those bundled features via the CLI:

codex features disable browser_use
codex features disable browser_use_external
codex features disable computer_use
codex features disable in_app_browser

drops the runtime marketplace to ["latex"], after which marketplace/add succeeds and config/read, configRequirements/read, thread/start, and experimentalFeature/list all return in milliseconds (0 timeouts across a full session). The "Full access" selector settles and local send works end-to-end — message dispatches, a new conversation is created, and the agent executes workspace tools. Connector/MCP plugins can stay fully enabled — it is specifically the three bundled browser/chrome/computer-use plugins' MCP handshake that exceeds the (too-aggressive) catalog startup timeout.

This confirms the root cause discussed above: the composer is hard-gated on bundled-marketplace tool-discovery with no timeout and no fallback, and a single slow bundled plugin stalls the whole catalog. Requested fix stands:

1. Make bundled/optional MCP startup non-blocking (incremental availability) so one slow plugin can't gate the composer/first turn.
2. Add a timeout → fallback to config.toml when isConfigDataPending can't resolve in a few seconds, instead of an infinite silent spinner.
3. Add per-bundled-plugin marketplace/add timeouts so browser/chrome/computer-use failing doesn't block latex or the send path.

Repro/environment: macOS 26.5.1, Apple M1 Ultra, Codex Desktop 26.601.20914 (app-server 0.136.0-alpha.2). Tracked in OpenAI support case 09438125.