[Windows + WSL2] Project creation fails on 26.908.4834.0; AbsolutePathBuf assignment sync error

Summary

In the Windows Codex desktop app with a WSL2 execution environment, creating a local project displays Failed to create project. Same-day desktop logs show an app-server project assignment sync error involving AbsolutePathBuf.

This appears closely related to #45008 (same app package version), #41463, and #44507. This report supplies another local observation; a shared root cause is suspected, not proven.

Environment

• Windows Codex desktop package version observed in the application log stack: 26.908.4834.0 (not independently checked in the About dialog).
• Agent execution environment confirmed as WSL2 Linux.
• Kernel: 6.18.33.1-microsoft-standard-WSL2, x86_64.
• Observation date: 2026-09-14, Asia/Shanghai (UTC+08:00).
• Windows build, WSL distribution version, bundled engine version, and subscription: not collected.

Observed steps

1. Open the Windows desktop app while using a WSL2 agent environment.
2. Open Create project.
3. Enter a project name (a Chinese display name was used in this case).
4. Add a local source folder. The dialog successfully shows the selected folder.
5. Click Create project.

Actual: The dialog remains open and a red toast says Failed to create project without actionable details.

Expected: Create the project with a correctly resolved source-folder path, or display the specific underlying error.

The exact selected source-folder absolute path was not captured. A Windows-native comparison, alternate project name, and clean-profile reproduction have not been tested. There is no evidence that the Chinese display name causes this failure.

Relevant local diagnostics

Two same-day desktop log entries:

2026-09-14T00:28:00.171Z warning [host-app-server-projects] Local app-server assignment sync failed
errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

2026-09-14T05:53:24.146Z warning [host-app-server-projects] Local app-server assignment sync failed
errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

The existing local projects returned by the app's project-list tool use Linux-form absolute paths such as /mnt/c/... and /mnt/d/....

Causality limitation: These log entries were recorded earlier than the screenshot. No project-create request/error directly correlated with that particular click was found. Windows/WSL path normalization is a hypothesis based on these observations and related reports, not a verified root cause.

Separate path-handling observation during diagnosis

When supplying the screenshot to the same WSL-backed task, attachment loading failed with:

Codex could not read the local image at `C:\Users\<user>\AppData\Local\Temp\codex-clipboard-<id>.png`: No such file or directory (os error 2)

A read-only filesystem check confirmed the image existed (183,040 bytes). Opening the same file with the corresponding /mnt/c/Users/<user>/AppData/Local/Temp/codex-clipboard-<id>.png path succeeded and displayed the image. This suggests a Windows-to-WSL attachment path handling problem; it is not proof that attachment loading and project creation share an implementation defect. The path substitution is a verified workaround for reading this screenshot only, not for project creation.

Requested investigation

Please investigate project assignment synchronization and source-path normalization at the Windows/WSL boundary, and expose the underlying project-create error in the UI. If this is the same defect as #45008, please consolidate this report there.

Only relevant sanitized log excerpts are included. The original screenshot contains unrelated work content, so it is not attached. No full logs, personal paths, or conversation transcripts are included.

Start by reviewing the project assignment synchronization and source-path normalization behavior at the Windows/WSL2 boundary, using the supplied reproduction steps and sanitized log entries. Compare the behavior with #45008, #41463, and #44507; done means identifying the shared failure and exposing the underlying project-creation error, or confirming that this report should be consolidated.