Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Sep 5, 2026
2. github-actions commented on Sep 5, 2026

   

   github-actionsBot

   on Sep 5, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • [Windows/WSL] Local project migration sends Windows paths to Linux app-server; project creation fails #42461
   • Windows Codex Desktop in WSL mode incorrectly converts /mnt/d/... to C:\d\..., breaking file tree and Project creation #42211

   Powered by Codex Action
3. travismartinjones commented on Sep 5, 2026

   

   travismartinjones

   on Sep 5, 2026 – with ChatGPT Codex Connector

   More actions

   Additional occurrence on Windows with the WSL2 / Ubuntu agent backend, using desktop package OpenAI.Codex_26.901.5280.0_x64__2p2nqsd0c76g0.

   Creating a project from an ordinary Windows directory also fails, so the selected new folder does not have to be inside the Linux filesystem. The UI displays only “Failed to Create Project”, and repeated attempts produce the same result. Read-only checks found that the folder exists, is readable, has normal Windows permissions, and is not a symlink or junction.

   Reproduction in the affected setup (path and name anonymized):

   1. Run the desktop app with Agent environment → Windows Subsystem for Linux, with existing saved local projects whose roots use Windows paths.
   2. Select a Windows folder such as C:\Development\example-project when creating a project.
   3. Enter a project name and submit.
   4. Observe the generic failure; retrying does not resolve it.

   The startup log after the WSL app-server connected contains:

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

   Additional evidence from read-only inspection of the installed application bundle:

   • In main-B6oTeDcE.js, runProjectWrite() waits for ensureProjectsReady().
   • Initialization imports existing legacy local projects before allowing the new project write.
   • writeAppServerProject() constructs the request's roots from the saved rootPaths without converting the paths to the selected backend's format.
   • In src-VqXTPopo.js, the app-server request transport forwards those parameters unchanged.

   This provides a code-level explanation for why the migration failure can block the creation dialog before the new project's own create request is sent: an existing C:\... root is passed to the Linux backend, where it is not an absolute Linux path, and project initialization fails. Changing only the newly selected folder would not fix the earlier import of existing roots.

   Expected behavior: valid Windows-folder selections should work with the WSL backend, and project-management failures should display actionable details.

   Suggested areas to fix: translate project roots for the selected backend on import/create/update; prevent a failed legacy-project migration from blocking unrelated new-project operations; surface the underlying error and affected project in the UI.

   Switching to Windows native is a plausible workaround for this occurrence, but has not been tested on this machine. The app and project files were not modified during diagnosis.
4. dmanexe commented on Sep 5, 2026

   

   dmanexe

   on Sep 5, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on the same Windows desktop package, with filesystem permission checks and a failure even when no folder is selected.

   Environment

   • Subscription: ChatGPT Pro.
   • Windows x64 desktop package: OpenAI.Codex_26.901.5280.0_x64__2p2nqsd0c76g0 (package version verified from executable path and logs; About-dialog version not collected).
   • Agent environment: Windows Subsystem for Linux.
   • WSL 2 distribution: Ubuntu.
   • Linux kernel: 6.18.33.2-microsoft-standard-WSL2.
   • Separately installed Linux CLI: codex-cli 0.145.0; this is not a claim about the desktop's bundled app-server version.

   Actual behavior and reproduction

   1. Run the Windows desktop app with Agent environment set to WSL and existing saved local projects.
   2. Create a project by entering a name and selecting a repository under Linux > Ubuntu in Windows Explorer, represented as \\wsl.localhost\Ubuntu\home\<user>\code\<repository>.
   3. The app repeatedly displays Failed to create project in a red error box.
   4. Also try creating a blank project by entering a name without selecting a folder. This fails with the same message in this installation.

   Creating a ChatGPT project on the website succeeds, although that is a different creation path and does not validate desktop local-project creation. Updating the desktop app and signing out and back in did not resolve the failures. A Windows-native control test has not been confirmed for this reproduction; WSL is required for the intended workflow.

   Observed logs

   The following startup error appears before and after the update, including packages 26.901.5003.0 and 26.901.5280.0:

   2026-09-05T17:57:44.156Z warning [host-app-server-projects]
   Local app-server project migration failed
   errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"
   

   The desktop logs detect Ubuntu as Running, WSL version 2. Searches around subsequent creation attempts did not expose a separate project-create exception or response explaining the toast. The inspected WSL login log also had no matching project/permission error.

   Filesystem checks

   Direct tests inside Ubuntu against all five existing saved repository directories passed directory traversal and temporary-file create/write/fsync/delete operations. All directories were owned by the current Linux user (UID 1000), mode 755. Temporary files were removed.

   An initial agent-run test returned read-only-filesystem errors because the diagnostic task sandbox did not have write access to those directories. After granting that access, every test passed. Those initial sandbox errors are not evidence of broken WSL filesystem permissions.

   Scope and hypothesis

   Saved local-project roots are Windows UNC paths. Inspection of the installed desktop code suggests local-project writes wait for project initialization/migration, and migration submits stored roots to the app server. That makes a migration/path-conversion failure a possible shared blocker. However, the exact failing request payload was not captured, and the startup error has not been causally tied to each failed creation. The blank-project failure means the issue should not be described as affecting only the newly selected Explorer folder.

   Expected: creating a project should succeed with WSL enabled and valid directories, or expose an actionable error. If migration of an existing project is blocking creation, surfacing the underlying migration error would make diagnosis much easier.

   Personal paths have been anonymized; no credentials or full session transcripts are included.
5. 84dnnvbdvp-debug commented on Sep 5, 2026

   

   84dnnvbdvp-debug

   on Sep 5, 2026 – with ChatGPT Codex Connector

   More actions

   Current public source sharpens the WSL path-translation hypothesis.

   codex-rs/utils/absolute-path/src/lib.rs shows that AbsolutePathBuf deserialization accepts an unguarded value only when PathBuf::is_absolute() is already true. On the Linux/WSL app-server, a persisted Windows drive path such as C:\\Users\\... is not a Linux-absolute path, and the platform-normalization branch is gated by cfg!(windows). With no AbsolutePathBufGuard base, that produces exactly AbsolutePathBuf deserialized without a base path.

   That lines up with the installed-bundle observation above that legacy Windows rootPaths are forwarded unchanged during project migration before new project writes.

   A narrow regression/fix boundary seems testable: start the Linux/WSL app-server, feed project migration a persisted Windows drive root, and assert Windows→WSL translation happens before the value crosses the AbsolutePathBuf deserialization boundary. If cross-backend saved projects are intended to migrate, translating after this point is too late. The malformed /mnt/.../resources/C:\\Users\\... shape is also consistent with a Windows path being treated as relative under Linux rather than with a filesystem-permission failure.

   Source: https://github.com/openai/codex/blob/7dc7c7a7566a970f6d4d09e1384f854aebaf39e0/codex-rs/utils/absolute-path/src/lib.rs
6. Carlo-Piccini commented on Sep 9, 2026

   

   Carlo-Piccini

   on Sep 9, 2026 – with ChatGPT Codex Connector

   More actions

   Additional affected installation on September 9, 2026, with evidence pointing to a legacy project migration blocking subsequent project writes.

   Environment

   • Windows app package: OpenAI.Codex_26.903.8094.0_x64
   • App-server version reported in the desktop log: 0.153.4
   • Backend launched through wsl.exe; Ubuntu-26.04 / WSL 2
   • Project persistence failures observed around 21:00–21:11 UTC.

   Observed state and logs
   The persisted .codex-global-state.json has a legacy local-projects entry with a Windows drive-letter rootPaths value. Sanitized equivalent:

   C:\Users\USER\OneDrive\Documents\Example Project
   

   The corresponding directory exists in WSL at /mnt/c/Users/USER/OneDrive/Documents/Example Project.

   At startup, after successful backend initialization:

   2026-09-09T20:20:00.705Z
   [host-app-server-projects] Local app-server project migration failed
   Invalid request: AbsolutePathBuf deserialized without a base path
   

   The UI reports “Failed to create project”. Using a ChatGPT project for a local task also repeatedly logs:

   ChatGPT project context sync failed
   stage=local-project-persistence
   projectSaveCount=0 sourceCount=0 syncFileCount=0
   
   Failed to prewarm local conversation
   Unknown local project
   

   Installed bundle inspection
   Read-only inspection shows this control flow:

   1. runProjectWrite awaits ensureProjectsReady() before a project write.
   2. initializeProjects imports unmigrated cached projects through writeAppServerProject("project/import", ...).
   3. writeAppServerProject maps stored rootPaths directly to roots: [{path: ...}], with no apparent Windows-to-WSL conversion on that path.
   4. A failed legacy import rejects initialization, which gates subsequent project writes.
   5. ChatGPT local context sync invokes upsertLocal after filesystem sync, matching the observed local-project-persistence failure.

   Working hypothesis
   A saved Windows root is rejected by the Linux backend during legacy migration. Because all project writes wait on migration, one incompatible saved entry appears to block unrelated project creation and ChatGPT-to-local project persistence.

   Please normalize legacy roots for the target backend before import, and consider isolating invalid legacy entries so they cannot block every project write. Exposing the underlying error in the UI would also help.

   Validation limits: This is based on live logs, persisted state, and installed-code inspection. No clean-profile reproduction or configuration repair has been performed, and the proposed path correction has not been tested. Paths and project names are anonymized; no credentials, full logs, or conversation transcripts are included.
7. HugoLumni commented on Sep 9, 2026

   

   HugoLumni

   on Sep 9, 2026 – with ChatGPT Codex Connector

   More actions

   Additional affected installation on September 9, 2026, with a controlled RPC probe supporting the path-conversion diagnosis above.

   Feedback ID: 01a08830-3254-7640-9788-1394471c050a

   Environment and observed behavior

   • Windows desktop package: OpenAI.Codex, package version 26.903.8094.0 (not an About-dialog version).
   • Local agent environment: WSL, Ubuntu.
   • Creating a local project from an existing Windows folder fails with the Portuguese UI message “Falha ao criar o projeto” (“Failed to create project”). The folder is accessible from both Windows and WSL.
   • Reproduction: keep the agent configured for WSL, create a local project, select an existing Windows directory, enter a name, and save. An anonymized example path is C:\Users\Example\projects\sample.
   • Expected: the project is created and appears in the sidebar while the agent remains in WSL. Switching to Windows native is not a suitable resolution for this workflow.

   Controlled app-server probe

   A separate probe sent project/update to the WSL app-server using a randomly generated project ID verified absent before and after the test. No project was created or changed by this probe.

   Root path format	Response
   Windows drive path	-32600: Invalid request: AbsolutePathBuf deserialized without a base path
   Equivalent absolute /mnt/c/... path	-32602: project not found

   The second response shows that the Linux path passes deserialization and reaches project lookup; it is not a successful-creation test. The AbsolutePathBuf error above came from this RPC probe, not from the UI toast. A separate workaround successfully created the requested project directly through the backend using the Linux path, bypassing the normal UI flow.

   Installed-source findings

   Inspection of main-C8LNyWut.js and an isolated execution test using a mocked connection and WSL-enabled environment predicate showed:

   1. createLocal / editLocal normalize roots through En/Tn to the Windows desktop format.
   2. AOe.writeAppServerProject maps roots directly to {path: ...} for project/create and project/import without converting them for the WSL backend.
   3. AOe.updateProject does the same for project/update; no later conversion was found for these project requests.
   4. In that isolated test, supplying /mnt/c/... as input is not sufficient: normalization converts it back to a Windows path before sending it.

   These are version-specific minified symbols. This source test is distinct from an end-to-end UI capture; the exact request responsible for the original toast was not captured.

   Candidate correction

   Convert project roots to the connection's execution-environment path format at the app-server request boundary for create/import/update, while preserving Windows-format paths where desktop filesystem operations need them. The inspected bundle already contains the hn converter and n.yi(connection.hostConfig) WSL predicate.

   The proposed correction has not been applied to or validated in a production build. Regression coverage should include Windows-mounted folders and WSL filesystem folders, paths with spaces/non-ASCII characters, and native Windows connections.
8. ChrisAwad-A20 commented on Sep 15, 2026

   

   ChrisAwad-A20

   on Sep 15, 2026

   Last edited by ChrisAwad-A20

   More actions

   Several duplicates exist for this root ticket --

   Problem still happening as of yesterday's build:
   Version 26.908.70816
   Released Sep 14, 2026

   Seems like the desktop app is having issues converting from paths like \\wsl$\Ubuntu-24.04\ to / for the WSL integration.

   If you ask me, when the WSL-native integration is enabled, the source folder browser for new projects should show Linux native paths from the get go instead of converting Windows paths after the fact to WSL native paths. It's completely counter intuitive the way the desktop app does it now. Codex needs to take a note from VS Code. VS Code does WSL integration properly.