Windows Desktop + WSL: AbsolutePathBuf errors break new sessions/plugins and archived remote threads are hidden

Summary

When using Codex Desktop on Windows with a WSL workspace, there appear to be two related remote-integration regressions:

1. Desktop-side actions such as creating a new session or installing/listing plugins can fail with:

Invalid request: AbsolutePathBuf deserialized without a base path

1. Archived threads that exist in WSL are not shown in the Desktop archived view, even though the underlying thread data is still present and the server can list it.

This looks like a Windows Desktop <-> WSL path/host bridging issue rather than data corruption in the WSL workspace.

Repro A: AbsolutePathBuf deserialized without a base path

User-visible behavior

On Windows Codex Desktop connected to a WSL project, actions like creating a new local/Desktop session or installing plugins can fail with:

Invalid request: AbsolutePathBuf deserialized without a base path

Technical repro

I reproduced the same error against a local app-server by sending a Windows absolute path in a request that expects AbsolutePathBuf:

• plugin/list.params.cwds is generated as AbsolutePathBuf[]
• thread/start.cwd / Thread.cwd are also AbsolutePathBuf

Sending this kind of payload to the app server:

{"id":1,"jsonrpc":"2.0","method":"plugin/list","params":{"cwds":["C:\\Users\\txc_king\\Documents\\Codex"]}}

returns:

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

That suggests the Desktop/bridge layer is forwarding a Windows path into a remote/WSL request path that needs a base path-aware AbsolutePathBuf conversion.

Repro B: archived WSL threads are hidden in Desktop

User-visible behavior

In Windows Codex Desktop, archived chats from the WSL side do not appear in the archived thread view.

What I verified

The archived thread data still exists on the WSL side:

• local state DB contained archived threads
• the app server can return them with thread/list when archived: true
• after unarchiving those same threads, they become visible again through the normal active thread list

So the data is not missing; the Desktop archived UI appears to be dropping or filtering remote/WSL archived threads.

Expected behavior

• Windows Codex Desktop should be able to create sessions and list/install plugins for WSL-connected workspaces without path deserialization errors.
• Archived WSL threads should appear in the Desktop archived view just like local archived threads.

Actual behavior

• Desktop actions fail with AbsolutePathBuf deserialized without a base path.
• Archived WSL threads remain hidden in the Desktop archived UI even though the server can still enumerate them.

Environment

• Observed on: June 28, 2026
• Host: Windows Codex Desktop connected to WSL2
• Guest OS: Ubuntu 24.04.2 LTS
• Kernel: Linux 5.15.167.4-microsoft-standard-WSL2
• CLI observed in WSL: codex-cli 0.141.0

Related issues

These may be related or duplicates of the same Windows/WSL integration class of bugs:

• #20014
• #25216
• #29600
• #30312

Workaround

A safe workaround for the archived-thread part is to unarchive the WSL threads so they return to the active thread list. That avoids the broken archived UI, but it does not fix the underlying Desktop bug.

If useful, I can also provide the exact thread/list and app-server validation details I used while reproducing this locally.