Windows Desktop thread/read succeeds but thread/resume rejects WSL runtimeWorkspaceRoots; restart restores chat #48583

Summary

Codex Desktop on Windows could read an existing chat but failed to resume it. The desktop log showed thread/read succeeding, followed by thread/resume returning -32600 Invalid request: AbsolutePathBuf deserialized without a base path. The chat history remained intact. Fully restarting Codex Desktop restored access according to the user; no successful persisted-state repair was applied during that restart.

Environment

• Windows Codex Desktop: 26.924.2738.0
• Bundled Windows app-server: 0.158.0-alpha.2.1
• The affected chat was created with a WSL-style workspace path on a Windows drive (for example, /mnt/c/Users/<user>/Documents/<workspace>), then opened by the Windows-native Desktop/app-server.

Observations

1. The Desktop log repeatedly showed a successful thread/read, then immediate failure of thread/resume with the AbsolutePathBuf error above. Opening the chat in the UI failed.
2. The stored conversation was readable. The same bundled Windows app-server, launched separately, could resume the chat when called with valid Windows-native path arguments. This does not prove that the Desktop sent those same arguments.
3. Local Desktop state still contained /mnt/c/... values in thread-workspace-root-hints and thread-projectless-output-directories. The thread metadata also contained a malformed Windows path of the form C:\mnt\c\....
4. A protocol-level probe against that bundled Windows app-server reproduced the exact AbsolutePathBuf deserialized without a base path error when a /mnt/c/... path was supplied in runtimeWorkspaceRoots. Supplying the WSL-style path only as cwd did not produce this error in the same probe.
5. After the user fully restarted Codex Desktop, the chat opened normally. The attempted helper that would have rewritten the global state failed before applying a patch; the persisted /mnt/c/... values were still present afterward. Thus the restart itself appears to have cleared a transient bad request/state condition. The actual Desktop thread/resume request payload was not captured, so the runtimeWorkspaceRoots link remains an inference.

Expected behavior

The Windows Desktop should translate or reject WSL-style workspace roots before sending them to a Windows app-server. A readable existing chat should resume without requiring an app restart, and a path error should identify the offending field and value.

Actual behavior

An existing chat could be read but not resumed. The UI was unusable for that chat until a full Desktop restart. No conversation data loss was observed.

Reproduction direction

1. Create/use a chat associated with a WSL-style workspace root on a Windows drive.
2. Open that chat through Windows-native Codex Desktop after the environment/path representation changes.
3. Observe thread/read success followed by thread/resume failing with -32600 Invalid request: AbsolutePathBuf deserialized without a base path.
4. Check whether runtimeWorkspaceRoots in the resume request contains /mnt/c/... rather than a Windows absolute path. This field was not captured from the failing Desktop process in this case.
5. Fully restart Desktop and retry. In this case, the chat opened again even though the persisted WSL-style hints remained.

Related reports

• Switching Codex from WSL to Windows-native breaks existing chats, rewrites /mnt/d paths as C:\mnt\d, and loses project associations #38781 documents existing chats failing after WSL to Windows-native switching and malformed C:\mnt\d\... paths.
• Windows + WSL: independent failures in Linux helper isolation, project-root RPC conversion, and persisted thread cwd #44918 documents other Windows/WSL path conversion and persisted cwd failures.

This report adds the thread/read versus thread/resume distinction, the runtimeWorkspaceRoots protocol reproduction, and recovery after restart without a successful state patch. All paths and chat identifiers above are redacted.