Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Plugins page fails in WSL mode when plugin/list receives Windows cwd [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20014•Fetched 2026-04-29 06:23:44
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
iamhectorlopeziamhectorlopez
Participants
github-actions[bot]github-actions[bot]iamhectorlopeziamhectorlopez
Timeline (top)
labeled ×5commented ×1

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.

Error Message

  • The visible error is Invalid request: AbsolutePathBuf deserialized without a base path.
  1. Observe that plugin loading fails with the AbsolutePathBuf error. {"error":{"code":-32600,"message":"Invalid request: AbsolutePathBuf deserialized without a base path"}}

Root Cause

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.

Code Example

Invalid request: AbsolutePathBuf deserialized without a base path

---

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

---

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

---

{"error":{"code":-32600,"message":"Invalid request: AbsolutePathBuf deserialized without a base path"}}
RAW_BUFFERClick to expand / collapse

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.

extent analysis

TL;DR

The issue can be resolved by ensuring that Windows-style paths are properly translated to WSL/Linux paths before sending the plugin/list request.

Guidance

  • Verify that the cwds parameter in the plugin/list request is being sent with a valid Linux-style path when running in WSL mode.
  • Check if the Desktop application is correctly translating Windows-style paths to WSL/Linux paths before sending the request.
  • Consider modifying the app-server to accept and normalize Windows-style paths when running in Desktop WSL mode.
  • Test the plugin/list request with a null cwds parameter to ensure that the plugin cache is not corrupted.

Example

No code snippet is provided as the issue is more related to path normalization and request handling.

Notes

The issue seems to be specific to the interaction between Codex Desktop and WSL execution, and the solution may depend on the specific implementation details of the application.

Recommendation

Apply a workaround to translate Windows-style paths to WSL/Linux paths before sending the plugin/list request, as this seems to be the most straightforward solution to resolve the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.

#tool integration#LLM response#prompt template#agent execution#callback error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Plugins page fails in WSL mode when plugin/list receives Windows cwd [1 comments, 2 participants]