[Windows][WSL][26.825.31414] Project creation and removal fail after switching Agent Environment to WSL

What version of the Codex App are you using (From “About Codex” dialog)?

26.825.31414

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

[Windows][WSL][26.825.31414] Project creation and removal fail after switching Agent Environment to WSL

What version of the Codex App are you using?

ChatGPT / Powered by Codex & OWL

Version: 26.825.31414
Release date shown in About: August 28, 2026

What platform is your computer?

Windows 11 x64 with WSL2 / Ubuntu.

What issue are you seeing?

Project management works correctly when the Codex Agent Environment is set to Windows Native, but stops working after switching the Agent Environment to Windows Subsystem for Linux.

The failure is not limited to WSL-hosted folders.

In Windows Native mode, I can successfully create a new Project from a normal Windows folder.

After switching the Agent Environment to WSL and restarting Codex Desktop:

creating a Project from a WSL folder fails;
creating a Project from a normal Windows folder also fails;
a Project that was successfully created earlier in Windows Native mode remains visible, but attempting to remove that Project also fails.

The only visible error when creating a Project is:

创建项目失败

("Failed to create project")

No more detailed error is surfaced in the UI.

This makes the failure appear tied to the selected Agent Environment / Project management backend, rather than to the selected folder itself.

Steps to reproduce

Control: Windows Native works

Open ChatGPT / Codex Desktop 26.825.31414.
Set:

Agent Environment = Windows Native

Fully restart the application.
Start a new conversation.
Select a normal Windows folder, for example:

C:\Temp\codex-project-test

Click Create Project.

Result:

Project created successfully.

Reproduction: switch to WSL

Change:

Agent Environment = Windows Subsystem for Linux

Fully restart the application.
Start a new conversation.
Select a WSL folder and click Create Project.

Result:

创建项目失败

Repeat using a normal Windows folder such as:

C:\Temp\another-project-test

Result:

创建项目失败

Locate the Project that was successfully created earlier while the Agent Environment was Windows Native.
Attempt to remove that Project while the Agent Environment is WSL.

Result:

Project removal also fails.

A/B result

The same Codex Desktop installation behaves as follows:

Windows Native
  └─ Windows folder
       └─ Create Project ✅

Switch Agent Environment to WSL
  ├─ WSL folder
  │    └─ Create Project ❌
  │
  ├─ Windows folder
  │    └─ Create Project ❌
  │
  └─ Project previously created in Windows Native
       └─ Remove Project ❌

This strongly suggests that Project CRUD becomes broken when the WSL Agent Environment is active.

Why this does not appear to be a folder-specific problem

I initially suspected a WSL path translation issue.

However, creating a Project from a normal Windows folder also fails when the Agent Environment is WSL.

Conversely, the same Windows folder works when the Agent Environment is Windows Native.

Therefore the distinguishing variable is:

Agent Environment = Windows Native → works
Agent Environment = WSL           → fails

rather than:

Windows filesystem → works
WSL filesystem     → fails

Additional symptom: cross-environment Project identity

A Project created successfully while running in Windows Native mode remains visible after switching the Agent Environment to WSL.

However, in WSL mode the application cannot remove that Project.

This may indicate that the Desktop UI retains the Project record while the active WSL-side Project management path cannot correctly resolve the Project's host/path identity.

For example, the same physical Windows folder may have representations such as:

C:\Temp\project
/mnt/c/Temp/project

If Project identity or CRUD operations depend on the currently selected execution host, switching environments may leave the Project visible but not resolvable by the active backend.

This is only a hypothesis based on the A/B behavior; I do not have a low-level error confirming the exact cause.

Logs

I attempted to search the local Codex Desktop logs immediately after reproducing the failure using Project / workspace / create / remove / WSL / path-related keywords.

I could not find a useful low-level error corresponding to the Project creation failure.

The UI currently exposes only the generic:

创建项目失败

toast.

A more detailed error in the UI or a clearly identifiable Project CRUD log event would make this problem substantially easier to diagnose.

Expected behavior

Switching the Agent Environment between Windows Native and WSL should not disable Project management.

In WSL mode:

a valid WSL folder should be usable to create a Project;
a valid Windows folder should either be correctly translated to /mnt/<drive>/... or rejected with an actionable path error;
existing Projects should remain removable;
Project identity should remain stable across Windows and WSL path representations;
changing Agent Environment should atomically switch the runtime without leaving Project state bound to the previous host representation.

Ideally, a saved Project should have a stable identity independent of whether the current execution path is represented as:

C:\...

or:

/mnt/c/...

Related issues

This appears related to the existing Windows/WSL Project identity and environment-switch problem family, but I could not find an existing issue reproducing this exact behavior on 26.825.31414.

Possibly related:

Windows App: WSL switch fails during provisioning, then hides history returned by thread/list #32902 — Windows App: WSL switch fails during provisioning, then hides history returned by thread/list
Codex Desktop project sidebar loses thread history when switching between Windows and WSL path views #30737 — Codex Desktop project sidebar loses thread history when switching between Windows and WSL path views
[Windows][WSL][Remote] Switching agent environment breaks WSL folder browsing and leaves stale Windows setup state #39639 — Switching agent environment breaks WSL folder browsing and leaves stale Windows setup state
Codex app on Windows: WSL agent mode fails with: Error creating task Invalid request: AbsolutePathBuf deserialized without a base path #16815 — WSL agent mode fails during task creation while Windows Native works
Codex Desktop fails to create new chats in WSL mode: invalid transport in mcp_servers.codex_app #40881 — WSL mode new-chat creation regression in the 26.820 release family

The important difference in this report is that on 26.825.31414:

Windows Native Project creation works;
switching to WSL makes all Project creation fail, including normal Windows folders;
Project removal also fails in WSL mode for a Project that was successfully created in Windows Native mode.

Impact

This blocks using Codex Desktop Projects with WSL as the Agent Environment.

The practical workaround is currently to keep the Agent Environment on Windows Native for Project management, or avoid Desktop Projects and use another Codex surface for WSL development.

Attachments

Available screenshots:

创建项目失败 toast after attempting Project creation in WSL mode.
About dialog showing:
- ChatGPT / Powered by Codex & OWL
- Version 26.825.31414
- Released August 28, 2026.

What steps can reproduce the bug?

Project management works correctly when the Agent Environment is set to Windows Native, but Project creation and removal stop working after switching the Agent Environment to WSL.

Reproduction:

Open ChatGPT / Codex Desktop 26.825.31414 on Windows.
Set Agent Environment to Windows Native.
Fully restart the app.
Start a new conversation and select a normal Windows folder, for example:
C:\Temp\codex-project-test
Click Create Project.
Confirm that the Project is created successfully.
Change Agent Environment to Windows Subsystem for Linux.
Fully restart the app.
Start a new conversation and select a folder inside WSL.
Click Create Project.
Project creation fails and the UI shows:
创建项目失败
("Failed to create project")
Repeat the test using a normal Windows folder while Agent Environment is still set to WSL.
Project creation also fails.
Try to remove the Project that was successfully created earlier while using Windows Native.
Project removal also fails.

A/B result:

Windows Native + Windows folder:
Create Project = works

WSL Agent Environment + WSL folder:
Create Project = fails

WSL Agent Environment + Windows folder:
Create Project = fails

WSL Agent Environment + Project previously created in Windows Native:
Remove Project = fails

This reproduces consistently and suggests that the failure is tied to the WSL Agent Environment rather than to a specific folder or filesystem.

What is the expected behavior?

Switching the Agent Environment from Windows Native to WSL should not break Project management.

When Agent Environment is set to WSL:

I should be able to create a Project from a valid WSL folder.
A valid Windows folder should either be correctly translated for the WSL environment or produce a specific actionable path error.
Existing Projects should remain removable.
Projects created while using Windows Native should remain manageable after switching to WSL.
Switching Agent Environment should not leave Project state bound to an incompatible Windows/WSL path or host representation.

Project identity and CRUD operations should remain stable across equivalent path representations such as:

C:\Temp\project

and:

/mnt/c/Temp/project

Additional information

Additional isolation results:

The problem is not limited to folders stored inside WSL.
A normal Windows folder can be used to create a Project successfully when Agent Environment is Windows Native.
The same type of Windows folder fails when Agent Environment is WSL.
A Project created successfully in Windows Native remains visible after switching to WSL, but it cannot be removed while WSL is active.
Switching back to Windows Native restores working Project creation.

Because both Windows and WSL folders fail only when the WSL Agent Environment is active, this appears to be a Project management / environment-switch issue rather than a filesystem permission problem in one specific folder.

I also attempted to find a more specific low-level Project creation/removal error in the local Codex Desktop logs immediately after reproducing the problem, but I could not find a useful Project CRUD error. The only user-visible message is the generic:

创建项目失败
("Failed to create project")

This makes the failure difficult to diagnose locally.

This may be related to existing Windows/WSL project identity and environment-switch issues:

Windows App: WSL switch fails during provisioning, then hides history returned by thread/list #32902 — Windows App: WSL switch fails during provisioning, then hides history returned by thread/list
Codex Desktop project sidebar loses thread history when switching between Windows and WSL path views #30737 — Codex Desktop project sidebar loses thread history when switching between Windows and WSL path views
[Windows][WSL][Remote] Switching agent environment breaks WSL folder browsing and leaves stale Windows setup state #39639 — Switching agent environment breaks WSL folder browsing and leaves stale Windows setup state
Codex app on Windows: WSL agent mode fails with: Error creating task Invalid request: AbsolutePathBuf deserialized without a base path #16815 — WSL agent mode fails during task creation while Windows Native works

However, I could not find an existing issue that reproduces this exact behavior on 26.825.31414:

Project creation works in Windows Native.
After switching to WSL, creating any Project fails, including Projects backed by normal Windows folders.
Removing a Project that was created successfully in Windows Native also fails while WSL is active.

Screenshot available showing the "创建项目失败" toast.

About dialog:
ChatGPT — Powered by Codex & OWL
Version 26.825.31414
Released August 28, 2026.

Same issue. ChatGPT desktop Version 26.825.31414

Current workaround: switch to Windows Native; create project -> use "\wsl$" directory -> skip the performance warning. this works. After that switch back to WSL backend and restart ChatGPT.

Same issue here. ChatGPT Desktop Version 26.825.32147

Confirming the same regression on another Windows + WSL installation.

Environment:

Codex Desktop package: 26.825.4187.0
Bundled app-server/runtime: 0.150.0-alpha.12.2
Last locally observed working startup: 26.820.9563.0 with app-server 0.150.0-alpha.8
Windows host with WSL2/Ubuntu agent environment

Observed behavior:

Creating a project fails with the localized UI toast equivalent to "Could not create project".
Editing/saving existing project definitions also fails.
Restarting the desktop app does not fix it.
The selected WSL folder exists, is accessible, and is already present in Codex trusted-project configuration, so this does not look like a simple missing-path or permission error.

The application log repeatedly records, beginning after the 26.825 update:

warning [host-app-server-projects] Local app-server project migration failed
Invalid request: AbsolutePathBuf deserialized without a base path

The failure reproduced multiple times after the update. Existing tasks and project listing remain available, but project create/edit persistence is broken while the WSL agent environment is active. This strongly matches the project migration / Windows↔WSL path normalization regression described here.

一样。无语，刚解决了wsl没法新建对话的问题，现在又没法创建项目了。

Advanced workaround used:

I fully closed Codex and backed up .codex-global-state.json and state_5.sqlite. I removed orphaned Project mappings and stale project_idempotency_keys entries that referenced missing Projects, but this alone did not fix the UI.

I then called project/create directly through the bundled Windows app-server using the same \wsl$\Ubuntu-26.04\home<wsl-user>\projects\portfolio path. The backend Project was created successfully.

Because it still did not appear in the sidebar, I linked the new backend Project to the legacy sidebar Project registry and restarted Codex. The Project then appeared and worked correctly with the WSL agent.

No repository files were modified. This indicates the failure is in Desktop’s WSL Project registration/sidebar synchronization rather than repository permissions.

Had some usage to kill so I just did this.

Today ChatGPT Desktop has been updated: Version 26.825.41651 and this issue persists.

My temporary workaround still works:

Switch to windows native
Restart ChatGPT
Create project using "\wsl$" directory (this would not fail)
Switch back to WSL2 backend
Restart ChatGPT and I can create sessions in the new project.

临时变通方法（详细教程）
第一步：切换 Agent environment = Windows native
第二步：Projectless task folder 可能需要重新处理确保它为 Windows 路径而非WSL路径否则无法导入/编辑项目（创建和移除的问题）
第三步：重启ChatGPT如果遇到UAC授权但是没有弹出授权进行以下操作

关于UAC无法正常弹出授权的问题处理指南

Win+R 输入 UserAccountControlSettings
修改通知权限为：图中所示
关闭ChatGPT右键以管理员权限启动如果找不到应用图片请在开始菜单搜索ChatGPT

Temporary Workaround (Detailed Tutorial)

Step 1: Switch Agent environment = Windows native

Step 2: The Projectless task folder may need to be reprocessed to ensure it is a Windows path instead of a WSL path; otherwise, importing/editing projects will fail (creating and removing issues).

Step 3: Restart ChatGPT. If you encounter a UAC authorization issue but the authorization prompt does not appear, perform the following steps:

Troubleshooting Guide for UAC Authorization Issues

Press Win+R and type UserAccountControlSettings
Modify notification permissions as shown in the image.
Close ChatGPT and right-click to start with administrator privileges. If you cannot find the application image, search for ChatGPT in the Start Menu.

Same problem here. Currently using 26.826.12353 version.

I can confirm the same regression on a newer build.

Environment:

Codex Desktop: 26.825.5331.0
Bundled CLI: 0.151.0-alpha.7.1
Windows 11 x64
WSL2, Ubuntu 25.04

Controlled A/B result:

Windows Native

Create a Project from a normal Windows folder: works
Rename the Project: works
Remove the Project: works

WSL Agent Environment (after a full app restart)

Create from a WSL folder: fails
Create from a normal Windows folder: fails
Rename an existing Project: fails
Remove an existing Project: fails
Pin and unpin the same Project: works

Switching back to Windows Native and fully restarting the app restores Project creation, rename, and removal.

The pin/unpin control suggests that ordinary sidebar state updates still work, while Project create/update/delete operations fail specifically in WSL mode. The Windows-folder control also rules out a problem limited to WSL-hosted folders.

The UI only shows generic failure messages. No authentication failure was involved; the behavior is consistently selected by the Agent Environment setting.

Problem still exists

I can confirm this regression on a newer Windows Desktop build and add a low-level reproduction that identifies the failing boundary.

Environment

Codex Desktop AppX: 26.825.6671.0
Desktop app-server client version observed in logs: 26.825.51511
Bundled Codex CLI: 0.151.0-alpha.7.2
Windows 11 Enterprise x64, build 26200
WSL 2.6.3.0, kernel 6.6.87.2-1
Ubuntu 24.04, WSL2
[desktop] runCodexInWindowsSubsystemForLinux = true

Additional symptoms

Creating a local Project fails while the Agent Environment is WSL.
Editing an existing Project and clicking Save fails even when the source folders are unchanged.
Changing only the Project icon/color appears to work despite the later generic save-error toast.

The icon behavior is explained by two separate requests:

The appearance control sends project/read, then project/update with metadata only. This succeeds, emits project/changed, and persists metadata such as:
```
{
  "appearance.color": "green",
  "appearance.marker": "{\"kind\":\"icon\",\"icon\":\"folder\"}"
}
```
Clicking Save sends another project/update containing the Project roots. That request fails, emits no project/changed, and leaves the Project updated_at unchanged. The appearance remains saved because the earlier metadata-only request succeeded.

Minimal app-server reproduction

With the WSL app-server running, this request shape fails:

{
  "method": "project/update",
  "params": {
    "projectId": "<project-id>",
    "name": "Example",
    "roots": [
      {"path": "C:\\Users\\example\\project"}
    ]
  }
}

Response:

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

The equivalent request succeeds when the root is translated before crossing the Windows-to-WSL bridge:

{"path": "/mnt/c/Users/example/project"}

This reproduces for project/create/project/import/project/update paths and supports the issue's hypothesis that the Desktop bridge is forwarding Windows absolute paths to a Linux AbsolutePathBuf deserializer without host-aware conversion.

Remote/history observation

The same path split can leave Remote and sidebar history grouped by stale cwd values. In the affected state, equivalent workspaces existed as both Windows paths and /mnt/c/... paths across state_5.sqlite and codex-dev.db, consistent with #30737 and #39639.

Successful project/changed events also reported targeted_connections=0, so a connected Remote client did not receive project-cache invalidation.

Confirmed workaround

The workaround already reported in this issue also works as the correct control:

switch Agent Environment to Windows Native;
fully restart Codex Desktop;
create/edit/remove the Project using a Windows path (or \\wsl$\... for a WSL-native folder);
switch back to WSL and restart.

Suggested fix

Convert Project roots through the active host path adapter before project/create, project/import, and project/update.
Do not re-submit unchanged roots when saving appearance/name-only changes.
Make the edit operation atomic or surface the failing sub-operation.
Ensure Remote clients either receive project/changed invalidation or refetch the project/thread grouping after reconnect.

same :(

Version 26.908.70816

Still not resolved

Confirmed that this still reproduces on a newer build:

Windows Codex Desktop 26.908.9136.0
Bundled WSL app-server 0.154.0-alpha.6.2
Windows + Ubuntu WSL2, Agent Environment set to WSL

Selecting a valid repository through \\wsl$\Ubuntu\home\<linux-user>\src\<repo>, entering a name, and clicking Create project produces the generic failure toast. The repository is valid, Windows can access both WSL UNC aliases, and the relevant SQLite databases pass integrity checks. The startup log contains:

[host-app-server-projects] Local app-server assignment sync failed
Invalid request: AbsolutePathBuf deserialized without a base path

The same machine reproduced this with a different repository on Desktop 26.901.6511.0, so it is not repository-specific.

Same

Apologies that this one has taken so long. We have a fix in place, and it will be included in the next release.

@etraut-openai

Apologies that this one has taken so long. We have a fix in place, and it will be included in the next release.

@etraut-openai cool, tks

I have the same issue. I'm using the version 26.911.61220

Apologies that this one has taken so long. We have a fix in place, and it will be included in the next release.

@etraut-openai cool, tks

No it is still not fixed, but there are improvements in version 26.911.61220. Now you could create a project if you do not add a directory. However if you add a windows directory in wsl (like \wsl.localhost\Ubuntu\home...) , project creation would fail

I'm still experiencing this issue after updating just five minutes ago. Does not matter how I try to create the project. Agent environment is Windows Subsystem for Linux and Integrated terminal shell is WSL.

@MiroKeimioniemi

I'm still experiencing this issue after updating just five minutes ago. Does not matter how I try to create the project. Agent environment is Windows Subsystem for Linux and Integrated terminal shell is WSL.

@MiroKeimioniemi
Try again, it works now

OK. It seems working now with Version 26.915.31029

Hooray!

@etraut-openai

Thank you @etraut-openai

OMG finally. that was VERY VERY long awaited fix. Finally I can create project and work in Windows ChatGPT app with WSL2

Confirmed workaround: stale legacy project blocks project initialization (Windows Native)

I encountered a related failure, but unlike the original report, I already had Windows Native agent execution enabled and was using WSL-hosted folders.

Environment: Desktop package 26.1002.7124.0; bundled app-server 0.162.0-alpha.2; Windows build 26200.9457; WSL package 3.0.1.0, Ubuntu on WSL 2.

Diagnosis

The UI showed only "Failed to create project". Desktop logs contained:

[host-app-server-projects] Local app-server assignment sync failed
Invalid request: AbsolutePathBuf deserialized without a base path

%USERPROFILE%\.codex\.codex-global-state.json contained an obsolete local-projects entry whose rootPaths used a Linux absolute path (/home/<user>/projects/<obsolete-project>). The original directory no longer existed; its contents had been relocated.

I inspected the installed Desktop initialization code and found legacy projects being imported before project initialization completed. A direct project/import request with that Linux root to the native Windows app-server reproduced the same deserialization error. Separately, project/create accepted a valid WSL UNC root. This showed that the native backend could accept that UNC root; it did not by itself establish why the UI request failed.

Workaround that resolved my issue

Manual internal-state repair, not an officially supported procedure. Back up first; do not apply indiscriminately to projects with associated chats.

Fully close Desktop and ensure no automation relaunches it during the edit.
Back up .codex-global-state.json.
Verify the obsolete project's exact ID and check existing/archived thread associations. In my case, a read-only inspection of state_5.sqlite found no threads with that project ID, including archived threads. There were historical automation threads with a related working-directory path but no project ID; those were left untouched.
Remove only that obsolete ID from local-projects and project-order. Inspect other ID references before editing; preserve unrelated entries.
Validate JSON and review the diff. Leave SQLite, session history, automation threads and filesystem directories untouched.
Restart Desktop once and verify both logs and UI creation.

Verified outcome after restart:

The obsolete project entry was not recreated.
Startup logged Local app-server project migration completed projectCount=8.
Neither of the assignment-sync/deserialization errors quoted above appeared in the inspected startup log.
I successfully created a new project through the normal UI.

Important pitfalls

Changes made to this state file while Desktop was running were overwritten by the application.
Bulk rewriting other projects' roots in JSON alone made existing chats disappear from their project views; restoring the backup recovered visibility. Do not treat root replacement as a safe migration procedure.
Changing between \\wsl.localhost\... and \\wsl$\... did not resolve this case.
No agent-environment switch, WSL shutdown, directory deletion or SQLite modification was needed.

Suggested product fix: handle invalid legacy entries individually so that one bad entry does not block project initialization; identify the offending project ID and path in an actionable error and provide a supported repair or removal flow.

@leksand86

issue should be closed now imho.

The latest comment #41290 (comment) appears to describe problem in reverse direction: Windows Native importing a saved Linux-path project. That may be a remaining path-conversion defect, but it doesn’t establish that the original WSL regression persists. @leksand86, seems like new issue should be opened

[Windows][WSL][26.825.31414] Project creation and removal fail after switching Agent Environment to WSL #41290

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

[Windows][WSL][26.825.31414] Project creation and removal fail after switching Agent Environment to WSL

What version of the Codex App are you using?

What platform is your computer?

What issue are you seeing?

Steps to reproduce

Control: Windows Native works

Reproduction: switch to WSL

A/B result

Why this does not appear to be a folder-specific problem

Additional symptom: cross-environment Project identity

Logs

Expected behavior

Related issues

Impact

Attachments

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

habaneraa commented on Aug 28, 2026

gaui commented on Aug 28, 2026

srmarron-star commented on Aug 28, 2026

quji762 commented on Aug 28, 2026

hbhatty commented on Aug 29, 2026

habaneraa commented on Aug 29, 2026

omount commented on Aug 29, 2026

jayn2u commented on Aug 30, 2026

herenfor commented on Aug 30, 2026

HFrancisla commented on Aug 30, 2026

aferende commented on Aug 30, 2026

Environment

Additional symptoms

Minimal app-server reproduction

Remote/history observation

Confirmed workaround

Suggested fix

crystaldaking commented on Aug 30, 2026

56 remaining items

ex-devo commented on Sep 15, 2026

austin42 commented on Sep 16, 2026

BurnyCoder commented on Sep 16, 2026

etraut-openai commented on Sep 16, 2026

matheusfelipeog commented on Sep 16, 2026

pjsde commented on Sep 17, 2026

xiaohanzhu commented on Sep 17, 2026

MiroKeimioniemi commented on Sep 17, 2026

wpf375516041 commented on Sep 18, 2026

xiaohanzhu commented on Sep 18, 2026

variousred commented on Sep 18, 2026

variousred commented on Sep 18, 2026

ekalkutin commented on Sep 19, 2026

leksand86 commented on Oct 8, 2026

Confirmed workaround: stale legacy project blocks project initialization (Windows Native)

Diagnosis

Workaround that resolved my issue

Important pitfalls

TyceHerrman commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions