Mac App stuck on splash logo: renderer pushes unsupported workspace_dependencies feature in tight retry loop, init never completes

What version of the Codex App are you using (From “About Codex” dialog)?

26.422.30944 (build 2080) (Bundled CLI runtime in /Applications/Codex.app/Contents/Resources/codex reports codex-cli 0.125.0-alpha.3. Homebrew-installed CLI, unaffected, is codex-cli 0.34.0.)

What subscription do you have?

ChatGPT Plus (Codex OAuth token JWT shows "chatgpt_plan_type": "plus")

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Codex.app gets stuck on the splash logo at launch. The main UI never appears. The app does not crash — it just sits on the logo indefinitely.

In ~/Library/Logs/com.openai.codex/<date>/codex-desktop-*.log, the renderer's main-process bridge fills the file with thousands of identical errors per second (the t0 log file passes 10 MB within 30 seconds of the app being open):

[electron-message-handler] Request failed
  conversationId=none
  durationMs=31
  error={"code":-32600,
         "message":"unsupported feature enablement `workspace_dependencies`:
                    currently supported features are
                    apps, memories, plugins, tool_search, tool_suggest, tool_call_mcp_elicitation"}
  method=experimentalFeature/enablement/set
[electron-message-handler] Failed to sync experimental feature enablement
  hostId=local

Each request has a fresh request id, so this isn't a single retry — the renderer is producing new requests in a tight loop and never gives up. Initialization appears to be gated on a successful sync of all enabled experimental features, and because workspace_dependencies is permanently rejected, init never completes.

Reinstalling the app from the official download does not fix it, because the mismatch is entirely inside the shipped .app bundle (see "Additional information" below for root-cause analysis).

What steps can reproduce the bug?

1. Install Codex.app version 26.422.30944 (the current public build at time of writing) on macOS Apple Silicon
2. Sign in with a ChatGPT Plus account
3. Quit the app fully
4. Launch /Applications/Codex.app
5. Splash logo appears, never transitions to the main UI
6. tail -f ~/Library/Logs/com.openai.codex/$(date +%Y/%m/%d)/codex-desktop-*-t0-*.log | grep workspace_dependencies shows the rejection error firing dozens of times per second

Session id: not available — no session is created because init never completes. Token / context-window usage: N/A for the same reason.

I have already attempted (none of these resolve it):

• Reinstalling the app from the official download
• Wiping ~/Library/Application Support/Codex/Local Storage (Statsig cache + leveldb)
• Wiping ~/Library/Application Support/Codex/sentry/
• Adding workspace_dependencies = false under [features] in ~/.codex/config.toml
• Forcing a Sparkle update check via defaults delete com.openai.codex SULastCheckTime

What is the expected behavior?

Codex.app finishes initialization and shows the main UI, regardless of whether any single experimental feature enablement call fails. Unsupported features should be logged and skipped, not block the entire renderer init flow.

Additional information

Root cause (from inspecting the shipped bundle):

• The renderer bundle (/Applications/Codex.app/Contents/Resources/app.asar) hardcodes the feature name workspace_dependencies — including a constant assignment (Sh = "workspace_dependencies"), feature-enablement gate checks of the form e.name === "workspace_dependencies" && e.enabled === true, and tool registrations (load_workspace_dependencies, install_workspace_dependencies).
• The bundled runtime binary (/Applications/Codex.app/Contents/Resources/codex, version codex-cli 0.125.0-alpha.3) has a strict allowlist for experimentalFeature/enablement/set. The supported set of feature names is exactly: apps, memories, plugins, tool_search, tool_suggest, tool_call_mcp_elicitation. workspace_dependencies is not in that list, so every set call returns -32600 unsupported feature enablement.
• Both halves of the mismatch ship inside the same .app bundle, which is why reinstalling the same build reproduces the bug exactly.

Suggested fixes (any one of these would unblock users):

1. Add workspace_dependencies to the runtime's enablement allowlist so it matches the renderer's expectations.
2. Have the renderer call experimentalFeature/list first and only push set for feature names the runtime advertises as known — silently skip unknown ones.
3. Stop blocking init progress on a successful enablement sync; log the failure and proceed.

Attached artifacts available on request:

• ~/Library/Logs/com.openai.codex/2026/04/26/codex-desktop-*.log (\~10 MB after a few seconds of being open, almost entirely the same error)
• ~/Library/Application Support/Codex/sentry/scope_v3.json (Sentry breadcrumb dump containing the same error)

PII / token redaction: I have not pasted log files inline because they may contain conversation/account identifiers; happy to share via a private channel if useful.