Codex dependencies show as not installed and reinstall fails from Settings on Windows
What version of Codex is running?
Unknown from UI; observed on May 5, 2026 in the Codex desktop app on Windows.
Which model were you using?
Codex desktop app.
What platform is your computer?
Windows
What happened?
In Codex desktop, under Settings > Configuration, the workspace dependency section shows:
Versione corrente:Non installata- Codex dependencies toggle enabled
When trying to recover from tool/runtime problems through the dependencies UI, the app shows these messages:
Potrebbe essere necessario correggere le dipendenze di Codex. Invia /feedback se il problema persisteImpossibile reinstallare le dipendenze di Codex
So the app recognizes a dependency problem, but reinstall from the Settings screen fails and leaves the dependency state as not installed.
Steps to reproduce
- Open Codex desktop on Windows.
- Go to Settings > Configuration.
- Look at the workspace dependencies section.
- Observe that current version is shown as
Non installata. - Attempt the recovery/reinstall flow for Codex dependencies.
- Observe the failure toast:
Impossibile reinstallare le dipendenze di Codex.
Expected behavior
If Codex dependencies are missing, the app should reinstall them successfully from Settings, or provide a clear actionable error explaining why installation failed.
Actual behavior
Dependencies remain in a not installed state and the reinstall action fails.
Additional context
This was visible directly in the Settings UI, under the workspace dependency section, while troubleshooting tool/runtime problems.
The UI also suggested sending feedback if the problem persisted. A previously uploaded feedback/thread ID associated with this troubleshooting session is:
019df9f1-7d90-7950-8e06-b329535708db
The issue seems specifically about Codex-managed dependencies in the app, not about the project repository dependencies.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I am seeing a very similar issue on Windows.
Environment:
In my case, the Workspace Dependencies “Diagnose” and “Reinstall” buttons are disabled / not clickable, so I cannot start the recovery flow from Settings.
Codex reports:
No bundled workspace runtime dependencies are configured yet.The Desktop logs repeatedly show:
unsupported feature enablement workspace_dependenciesThe related request is:
experimentalFeature/enablement/setThe error message says the currently supported features are:
apps, memories, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitationbut
workspace_dependenciesis not included.This looks related to the same Codex-managed workspace dependencies problem, but in my case the recovery buttons are disabled before reinstall can even be attempted.
Related to #21247, but in my case the Diagnose/Reinstall buttons are disabled before the reinstall flow can even start.
I've managed to fix this issue by entering proper npm proxy setting. Our org requires all traffic to go through a proxy, and apparently npm didn't use the system-wide settings.
npm config set proxy=https://ip:portSame issue, but recovery buttons were clickable
I hit what looks like the same issue on Windows, but my recovery buttons were clickable.
Environment
Symptoms
Relevant logs
unsupported feature enablement
workspace_dependenciescurrently supported features are apps, memories, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation
I also saw runtime extraction failures:
primary_runtime_install_failed
Failed to extract primary runtime archive
Can't create ... C:\Users\<user>\.cache\codex-runtimes\...\codex-primary-runtime\dependencies\node\node_modules\docx: Invalid argument
Can't create ... node_modules\playwright: Invalid argument
Can't create ... node_modules\sharp: Invalid argument
Workaround that fixed it for me
apps = trueunder[features]inC:\Users\<user>\.codex\config.toml.Example:
[features]
memories = true
hooks = true
apps = true
After recovery, mine showed:
Current version: 26.506.11943
This was not an npm proxy issue in my case.
Not sure whether both
apps = trueand the one-time Administrator launch are required, but that exact combo fixed it for me.