Windows Desktop: workspace_dependencies feature mismatch persists after local recovery

Open 💬 2 comments Opened May 7, 2026 by felixfisher

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:

  1. config.toml had corrupted [projects] entries involving non-ASCII project paths.
  2. A previous primary runtime install attempt had failed while extracting deep node_modules/.pnpm/... paths on Windows.
  3. 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?

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗