Plugins page fails in WSL mode when plugin/list receives Windows cwd

Open 💬 2 comments Opened Apr 28, 2026 by iamhectorlopez

Summary

In Codex Desktop on Windows with WSL execution enabled, opening Plugins > Manage can fail with:

Invalid request: AbsolutePathBuf deserialized without a base path

This looks like a Desktop-to-WSL path normalization issue rather than a plugin cache or marketplace manifest problem.

Symptoms

  • The Plugins management page shows Failed to load plugins.
  • The visible error is Invalid request: AbsolutePathBuf deserialized without a base path.
  • Installed apps, MCPs, and skills may still be present, but the plugin list request fails.

Reproduction outline

  1. Run Codex Desktop on Windows with WSL execution enabled.
  2. Open Plugins > Manage from a thread/workspace whose UI-side path is Windows-style, for example C:\Users\<user>\Documents\Codex.
  3. Observe that plugin loading fails with the AbsolutePathBuf error.

Debug evidence

Calling the app-server directly with no cwd succeeds:

{"method":"plugin/list","params":{"cwds":null,"forceRemoteSync":false}}

The same request shape with a Windows-style cwd fails when the app-server is running under WSL/Linux:

{"method":"plugin/list","params":{"cwds":["C:\\Users\\<user>\\Documents\\Codex"],"forceRemoteSync":false}}

Response:

{"error":{"code":-32600,"message":"Invalid request: AbsolutePathBuf deserialized without a base path"}}

When cwds is omitted/null, the same plugin cache returns the expected bundled and curated marketplaces, so this does not appear to be caused by corrupted plugin manifests.

Expected behavior

The Plugins management page should load in WSL mode. Either Desktop should translate Windows paths to WSL/Linux paths before sending plugin/list, or the app-server should accept and normalize Windows-style paths when running in Desktop WSL mode.

View original on GitHub ↗

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