Windows Desktop: workspace_dependencies feature mismatch persists after local recovery
What happened
On Windows 11, Codex Desktop entered an inconsistent workspace UI state. Some conversations/projects showed the file tree and terminal/workspace controls, while other existing conversations/projects did not. After restarting the app, some historical conversations did not restore cleanly, and the app sometimes prompted for sandbox configuration before continuing.
After local recovery steps, the app became mostly usable again, but the Desktop logs still consistently show a feature negotiation mismatch for workspace_dependencies.
Environment
- OS: Windows 11 x64
- Codex Desktop package version observed:
26.429.x - App-server version reported in logs:
0.128.0-alpha.1 - A global npm Codex CLI was also present, but Desktop appears to use its own packaged app-server
- Windows long-path support is enabled
Relevant log excerpt
The app-server initializes successfully:
[AppServerConnection] Current reported app-server version: currentVersion=0.128.0-alpha.1
[AppServerConnection] initialize_handshake_result ... outcome=success
[AppServerConnection] Codex CLI initialized
But the Desktop renderer still attempts to enable workspace_dependencies, which the local app-server reports as unsupported:
[electron-message-handler] Features enabled enabledFeatures="..., workspace_dependencies, ..."
[electron-message-handler] Request failed ... method=experimentalFeature/enablement/set ...
error={"code":-32600,"message":"unsupported feature enablement `workspace_dependencies`: currently supported features are apps, memories, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation"}
Related local findings
Before cleanup, this Windows environment also had a few local issues:
config.tomlhad corrupted[projects]entries involving non-ASCII project paths.- A previous primary runtime install attempt had failed while extracting deep
node_modules/.pnpm/...paths on Windows. - One MCP server appeared to emit non-JSON process termination output into the app-server stdio stream, causing MCP parse errors.
After cleanup, the config parses correctly, corrupted project records were removed, the MCP parse errors are gone, and no new runtime extraction failures are visible. However, the workspace_dependencies feature mismatch still remains.
Why this looks like a Desktop/app-server version mismatch
The Desktop renderer includes workspace_dependencies in the feature enablement list, but the bundled app-server for this Desktop build does not list it as a supported feature. Updating the global npm CLI does not appear sufficient, because Codex Desktop uses its own packaged app-server.
This looks similar to:
- #19770
- #19437
- #19279
- #19873
Expected behavior
The Desktop renderer and bundled app-server should agree on supported experimental features. If workspace_dependencies is not supported by the bundled app-server, Desktop should not attempt to enable it, or it should handle the mismatch without affecting workspace/project UI state.
Actual behavior
Desktop sends experimentalFeature/enablement/set for workspace_dependencies, and app-server rejects it with -32600. On this Windows machine, this previously correlated with missing workspace controls in some existing conversations/projects.
Question
Is there a recommended Windows recovery path for this mismatch besides waiting for a Desktop update? Should affected users reset a specific Desktop cache, runtime bundle, or feature flag state, or is this purely a packaged-version issue that needs to be fixed in a Codex Desktop release?
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗