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

Open 💬 2 comments Opened Apr 28, 2026 by iamhectorlopez
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 ↗

2 Comments

github-actions[bot] contributor · 4 months ago

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

  • #18506
  • #19052

Powered by Codex Action

xiaodream551-a11y · 3 months ago

Additional repro for the same AbsolutePathBuf deserialized without a base path class, but from the Add plugin marketplace dialog rather than plugin/list.

Environment:

  • Codex Desktop on Windows
  • Codex CLI: 0.130.0
  • WSL distro: Ubuntu 24.04
  • Current workspace is opened through a WSL path such as \\wsl.localhost\Ubuntu-24.04\home\<user>

Repro:

  1. Open Codex Desktop on Windows in a WSL workspace.
  2. Go to Plugins -> Create -> Add plugin marketplace.
  3. Enter a local WSL UNC marketplace root as the source, for example:

``text
\\wsl.localhost\Ubuntu-24.04\home\<user>\.agents\plugins\openai-curated-local
``

  1. Leave Git ref empty. For local sources, leave sparse path empty as well.
  2. Submit.

Observed:

The UI reports add marketplace failure. The user-visible/backend error is:

Invalid request: AbsolutePathBuf deserialized without a base path

Expected:

The app should either accept and normalize WSL UNC local marketplace paths, or reject them with a clear validation message before sending the request to the app server.

Additional note:

The same local marketplace can be added successfully outside the dialog using a Windows-local path:

codex plugin marketplace add C:\Users\<user>\.agents\plugins\openai-curated-local

This writes a working config entry like:

[marketplaces.openai-curated-local]
source_type = "local"
source = '\\?\C:\Users\<user>\.agents\plugins\openai-curated-local'

There is also a separate validation footgun in the dialog: if the Sparse path field is left populated while adding a local folder, the CLI-equivalent error is:

--sparse is only supported for git marketplace sources

The dialog should probably clear/disable sparse path when the source is detected as a local folder, or surface that specific validation error instead of a generic add failure.