Codex Desktop WSL2: malformed project paths, rejected Linux symlinks, and pasted images inaccessible to image tool

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

OpenAI.Codex_26.903.8094.0_x64__2p2nqsd0c76g0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows: Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Environment

• Subscription: ChatGPT Plus
• Windows: Microsoft Windows NT 10.0.26200.0 x64
• Codex desktop package: OpenAI.Codex_26.903.8094.0_x64__2p2nqsd0c76g0
• Agent environment: WSL2, switched from Windows native followed by an app restart
• WSL distribution name: RHEL-10
• Linux distribution: Red Hat Enterprise Linux 10.2 (Coughlan)
• Kernel: Linux 6.18.33.2-microsoft-standard-WSL2 x86_64
• Shell: /bin/bash
• Bubblewrap: 0.10.0, installed and verified
• Example Linux home: /home/devuser
  Privacy note
  Usernames, project names, and attachment identifiers below are fictional replacements. The path structures, error messages, technical versions, and diagnostic outcomes reflect the observed behavior.
  Summary
  After switching Codex Desktop to WSL2, shell commands execute inside Linux, but project selection, project-path migration, and image tools do not consistently access the same filesystem.
  Three failures were observed:

1. An existing Windows project path became a malformed Linux working directory.
2. Project selection rejected a valid path through a Linux symbolic link.
3. Pasted images were reported missing by the image tool even though sandboxed Bash could read the same files.
4. Existing project path becomes malformed after switching to WSL2
   Example original project:
   C:\Work\Projects\SampleProject
   After restarting in WSL mode, the task’s supplied working directory and project write-permission root had this malformed structure:
   /mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.903.8094.0_x64__2p2nqsd0c76g0/app/resources/C:\Work\Projects\SampleProject
   The correct Linux-accessible destination would be:
   /mnt/c/Work/Projects/SampleProject
   Steps to reproduce
5. Open a project using its Windows path in Windows-native agent mode.
6. Change Agent environment to WSL.
7. Fully restart the app.
8. Resume the existing task.
9. Inspect the working directory and project permission roots supplied to the agent.
   Actual behavior
   The Windows absolute path is appended to the application resources directory instead of being mapped to a valid Linux path.
   Expected behavior
   Translate or rebind the existing project to its valid path in the selected WSL distribution. Apply that mapping consistently to the working directory and project permission roots.
10. Project picker rejects a valid path through a Linux symbolic link
    Example project path:
    ~/worklink/Projects/SampleProject
    In this example, worklink is a Linux symbolic link to /mnt/c/Work.
    Bash successfully resolves the project:
    readlink -f ~/worklink/Projects/SampleProject
    Example output:
    /mnt/c/Work/Projects/SampleProject
    Opening the equivalent path through the desktop project picker:
    \wsl$\RHEL-10\home\devuser\worklink\Projects\SampleProject
    produces a Select Project Root dialog stating:
    The folder name is not valid.
    The picker appears to treat the Linux symbolic link as a file rather than traversing it. The same actual symbolic link and project are accessible in Cursor’s WSL integration.
    Expected behavior
    Project selection in WSL mode should resolve Linux paths and symbolic links through the selected distribution, including links to Windows-mounted directories.
11. Pasted image exists and is readable in WSL, but image tool reports it missing
    Pasting an image generated a Windows temporary-file reference with this structure:
    C:\Users\winuser\AppData\Local\Temp\codex-clipboard-00000000-0000-4000-8000-000000000001.png
    The attachment failed to load with:
    No such file or directory (os error 2)
    Both the user and agent verified that the corresponding file existed and was readable through Bash:
    ls -l '/mnt/c/Users/winuser/AppData/Local/Temp/codex-clipboard-00000000-0000-4000-8000-000000000001.png'
    The original screenshot was a readable, 9,348-byte PNG.
    Diagnostic results

• view_image on the equivalent /mnt/c/... path reported the file missing.
• Bash successfully copied the image to /tmp/pasted-image.png.
• view_image on that /tmp copy also reported it missing.
• Passing a forward-slash Windows path, C:/Users/..., to view_image caused the tool to prepend the malformed working directory.
• Reading the PNG bytes through Bash, Base64-encoding them, and passing a data URL directly to the image renderer succeeded. The agent then correctly read the screenshot.
  Sandbox verification
  Bubblewrap 0.10.0 is installed, and normal sandboxed Bash commands succeed.
  After installation, sandboxed Bash successfully listed the screenshot in /tmp. The image tool was retested against the same path and continued to report:
  unable to locate image at /tmp/pasted-image.png: No such file or directory (os error 2)
  The image-tool failure therefore persists with Bubblewrap installed and sandboxed shell access working.
  Expected behavior
  Pasted images and image tools should access files available in the agent’s WSL environment without requiring users to save screenshots manually or agents to transfer image bytes through shell output.
  These tests establish that the screenshot exists, is readable through Bash, and is decodable. They do not establish the internal cause of the image tool’s filesystem mismatch.
  Impact
  Switching to WSL2 left an existing task with an invalid project path, prevented reopening the project through its normal Linux symbolic link, and broke direct image-tool access to pasted screenshots.
  I use Bash and WSL2 as my development environment. Switching to Windows-native execution or bypassing normal Linux paths does not satisfy that workflow. The same symbolic link works in Cursor.
  Requested resolution
  Please investigate and correct:

1. Existing project-path migration when switching from Windows-native execution to WSL2.
2. Project selection and symbolic-link traversal within the selected Linux distribution.
3. Filesystem consistency between shell execution, pasted-image attachments, and view_image.
   Please provide a supported fix and an issue-tracking reference.

What steps can reproduce the bug?

Steps to reproduce

1. Open a project using its Windows path in Windows-native agent mode.
2. Change Agent environment to WSL.
3. Fully restart the app.
4. Resume the existing task.
5. Inspect the working directory and project permission roots supplied to the agent.

What is the expected behavior?

Translate or rebind the existing project to its valid path in the selected WSL distribution. Apply that mapping consistently to the working directory and project permission roots.

Additional information

No response

Run the listed WSL2 reproduction steps first, checking the supplied working directory and project permission roots after switching from Windows-native mode. Then compare project-picker handling of the Linux symlink and view_image access for the pasted image against the successful Bash checks; done means valid project paths, symlink traversal, and direct image access work consistently in WSL2.