Codex macOS startup failure: unsupported feature enablement `workspace_dependencies`

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #18842
• #18456

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. Codex VS Code extension fails to enable realtime_conversation; new chats cannot switch model and Output is flooded with worker warnings #18842 Windows desktop app regression after in-app upgrade: settings/language break, slash commands stop working, Fast Mode missing #18456 _Powered by Codex Action_

Not a duplicate of the suggested issues.

#18842 is related to the VS Code extension on Windows (realtime_conversation + worker warnings), and #18456 is a Windows desktop app regression after upgrade (settings/slash commands/Fast Mode).

This issue is specific to the macOS Codex desktop app failing at startup with:

unsupported feature enablement workspace_dependencies

The failure occurs before any workspace/session loads, and account/read succeeds, indicating a runtime/feature mismatch rather than a UI or extension issue.

Happy to provide additional logs or test fixes if needed.

It sounds like you have an invalid feature flag entry in your config file. Open ~/.codex/config.toml and search for "workspace_dependencies".

It's bricked for me too, deleting the config file did not help. Bricked in codex app also in vs code and also antigravity. It's only a problem since updating

Also I noticed it's eating lots of ram

Same here. No reference to "workspace_dependencies" in the config.toml; just totally bricked as of today.

Hate to be "that guy", but... maybe Codex's coders ought to do less vibe coding and more hands-on testing.

EDIT: I updated the CLI (had to rm the Brew cask manually), logged out and then back in. I'm all good now.

Just did an update, which I was prompted to in the app, and it is broken on wakeup

Update: I was able to resolve this locally by signing out of the Codex macOS app and signing back in.

I did not need to delete ~/.codex, remove my config, or reinstall via Homebrew. My Homebrew check returned no Codex install/cask.

This suggests the failure may involve stale auth/session state or feature-flag negotiation rather than only a local config.toml issue. After re-auth, the app launched successfully again.

Confirming this is still present on a newer build.

Setup

• macOS 26.4 (arm64)
• Codex app: 26.422.21637 (newer than OP's 20832)
• Bundled CLI (.../Contents/Resources/codex): codex-cli 0.124.0-alpha.2
• ~/.codex/config.toml does not contain workspace_dependencies

What I tried (all failed to fix it)

• Full uninstall: deleted /Applications/Codex.app, ~/Library/Application Support/Codex, ~/Library/Preferences/com.openai.codex.plist, ~/Library/Caches/com.openai.codex, ~/Library/HTTPStorages/com.openai.codex*, ~/Library/Logs/com.openai.codex, ~/Library/Application Support/com.openai.chat/codex-*, plus the CrashReporter and LaunchServices sidecar files
• Fresh DMG download + reinstall

Runtime behavior after clean reinstall

• The window never renders. Electron main process runs fine but the renderer repeatedly throws:

``
[desktop-notifications][unhandled-rejection] Error: WorkerPoolManager: workers failed to initialize
``

• stdout shows ~150 rejected experimentalFeature/enablement/set calls for workspace_dependencies in the first 20s, each returning -32600:

``
unsupported feature enablement workspace_dependencies:
currently supported features are apps, memories, plugins, tool_search,
tool_suggest, tool_call_mcp_elicitation
``

Re the sign-out/sign-in workaround from @SnowfallHD / @entif-ai — that requires the window to render, but on this build the renderer dies before any settings UI is reachable, so it's not a viable self-recovery path.

Looks like a frontend/backend version skew inside the shipped .app: the Electron frontend asks the bundled codex-cli 0.124.0-alpha.2 to enable workspace_dependencies, which that CLI version doesn't understand. Reinstalling doesn't help because both components ship together.

Follow-up — workaround that worked for me.

Since the app UI never renders, the sign-out/sign-in fix can't be done from the desktop app itself. But you can do it via the Codex CLI:

codex logout
codex login

I used the Homebrew-installed codex-cli (v0.114.0, stable) to do this — no need to touch the bundled alpha CLI inside the .app. After re-authenticating, the Codex desktop app launched cleanly on the next try.

So for anyone with a bricked UI who can't reach the in-app Sign Out button: resetting auth via the CLI is a viable self-recovery path. No reinstall or config edits needed.

Root cause still appears to be the frontend/backend version skew described above — but a fresh token seems to sidestep the workspace_dependencies feature-negotiation failure.

Also I noticed it's eating lots of ram

The codex desktop app continously prints logs in an infinite loop while that failure is a thing, which is also an issue.

I did the same workaround as @cole-jxn, this UI lockout / render-fail issue is related to a specific auth token-issue. Seems like the latest update breaks the UI if the auth token is expired.

Same issue it appear to be the app version is broken on both window and macOS.

No stuck loading on ui issue.

I tried this and it worked only problem is it didnt have gpt 5.5. Chatgpt instructions:

macOS fix — M-series Mac / Apple Silicon

1. Fully quit Codex

Open Activity Monitor, search:

Codex

Force quit anything Codex-related.

Or use Terminal:

pkill -f Codex

1. Move the broken app out of Applications

In Finder:

Applications → Codex.app

Move it to Trash.

Or Terminal:

mv /Applications/Codex.app ~/Desktop/Codex-broken.app

1. Download the known working version

Open Terminal and run:

curl -L -o ~/Downloads/Codex-26.417.41555.zip "https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.417.41555.zip"

That is the exact Apple Silicon downgrade URL mentioned in the GitHub workaround.

1. Unzip it

ditto -xk ~/Downloads/Codex-26.417.41555.zip ~/Downloads/Codex-26.417.41555

Then open:

Downloads → Codex-26.417.41555

Drag Codex.app into Applications.

1. Open Codex

Open it from:

Applications → Codex

If macOS blocks it, run:

xattr -dr com.apple.quarantine /Applications/Codex.app

Then open it again.

It worked, I then decided to update it but it to latest version but then it then had same issue. We likely need to wait for a patch.

I Fixed the issue!!!!

This issue it codex cli auth token.

First do codex in your terminal.

Then logout.

Then sign back in to codex using whatever version.

It fixed both cli and app.

Do /logout

Then start up cli again

i did also upade node and npm to latest, not sure if this bit fixed the issue.

But this def works on both windows and macos

Paste my response into chatgpt for terminal comands ;)

Additional update: after re-authentication, Codex and related services appear to be working somewhat again, but I’m still seeing instability on ChatGPT web with the Pro plan.

Specifically, when using GPT-5.5 with reasoning above Standard Thinking (for example Extended or Heavy) and giving it a prompt that asks it to perform actions, the request hangs/breaks. The page needs a refresh, and the prompt does not appear to register at all.

Dropping back down to Standard Thinking makes normal prompting more reliable, but autonomous/action-style behavior from ChatGPT still appears unreliable on GPT-5.5.

This may be related to the same rollout/session/feature-negotiation issue, but I’m not sure.

Had the same issue. Logging out/in in codex cli fixed it for me as well.

same issue here with macos app stuck before sign in

fix: run codex login from terminal, sign in again in the website, then launch the macos app

+1 on logout/login workaround either via cli or otherwise.

Thank you for raising this issue. I'd like to share additional context as I encountered the exact same problem.

Reproducing after in-app update + additional context

• Codex version: 26.422.30944 (build 2080)
• macOS: 26.3 (Build 25D125), Apple Silicon (aarch64)
• Trigger: Clicked the in-app update button → update started → app entered broken state immediately after

Symptoms:

1. JavaScript error dialog loops repeatedly: Connection for host ID local not found (cannot dismiss — pressing OK causes it to reappear immediately)
2. After force-killing via pkill, app relaunches to permanent white/spinner screen — never finishes loading

Confirmed via logs (~/Library/Logs/com.openai.codex/):
workspace_dependencies enablement error repeating every ~65ms in the main process log. The ready message IS sent (app routes mounted after ~48000ms) but the UI never renders.

error [electron-message-handler] Failed to sync experimental feature enablement
error={"code":-32600,
       "message":"unsupported feature enablement `workspace_dependencies`:
       currently supported features are apps, memories, plugins,
       tool_search, tool_suggest, tool_call_mcp_elicitation"}
hostId=local

Attempted workarounds (none resolved):

• Cleared: Cache, Code Cache, GPUCache, Session Storage, Local Storage (both main partition and codex-browser-app partition)
• Uninstalled and reinstalled app (same version 26.422.30944)

Additional note:
Secondary errors also present — registered workspaces referencing paths that no longer exist on disk (ENOENT: path does not exist) — but these appear to be warnings only and not the root cause of the startup failure.

---
Posted via Claude Code

We understand the cause of this problem, and a fix will be included in the next release.

I investigated this while building a local Codex.app pool bridge on macOS, and the current evidence suggests the workspace_dependencies warning is not caused by the bridge.

What I verified on Apple Silicon macOS:

• Normal launch: /Applications/Codex.app/Contents/MacOS/Codex --help
• app-server child: /Applications/Codex.app/Contents/Resources/codex
• reported app-server version: 0.126.0-alpha.8
• still emits unsupported feature enablement \workspace_dependencies\``

• Pooled launch through bridge:
• bridge starts poolctl lease app-server ... --codex-bin /Applications/Codex.app/Contents/Resources/codex
• reported app-server version: 0.126.0-alpha.8
• emits the same unsupported feature enablement \workspace_dependencies\`` warning

Before fixing the bridge, pooled mode was incorrectly reusing a terminal-pool frozen CLI (codex-cli 0.0.0), which did create a separate protocol/version skew. I fixed that locally so pooled launch now uses the bundled desktop CLI by default. After that fix, pooled and normal launches converge on the same workspace_dependencies warning.

So the remaining issue appears to be in the desktop/app-server feature negotiation itself, not in the pool bridge wrapper.

If useful, I can also provide the exact app logs showing:

• Current reported app-server version: currentVersion=0.126.0-alpha.8
• repeated experimentalFeature/enablement/set failures for workspace_dependencies
• reproduction for both launch paths on the same machine

Closing as resolved.