Codex Desktop Windows: image attachment saved to Temp but not accessible to WSL agent/view_image

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

• #25983

Powered by Codex Action

I have the same issue, very annoying

Also reproduced on 2026-06-21 in Codex Desktop on Windows with a WSL workspace. Two pasted PNGs were exposed only as C:\Users\<user>\AppData\Local\Temp\codex-clipboard-<uuid>.png; both failed with No such file or directory (os error 2).

Additional diagnostic: retrying the mapped /mnt/c/Users/<user>/AppData/Local/Temp/... path with view_image, and running exec_command, both failed before filesystem access because the sandbox helper panicked:

bubblewrap is unavailable: no system bwrap was found on PATH and no bundled
codex-resources/bwrap binary was found next to the Codex executable

This prevents copying the attachment into the workspace as a workaround. Expected: pass pasted images as image input or use a temp location shared with the WSL agent; also ship/configure a working WSL sandbox helper.

I dug through the local source history because this appears to have started surfacing in June for Windows Desktop + WSL users.

Best regression-window candidate for the user-visible behavior is #25944, merged 2026-06-03 (57ab4c89e05d13b81722780ffc50eee0ea6cf445). Before that change, successful local-image prompt framing exposed only the label:

<image name=[Image #1]>

After #25944, successful local-image framing includes the source path:

<image name=[Image #1] path="C:\Users\<user>\AppData\Local\Temp\codex-clipboard-<uuid>.png">

That lines up with the current symptom where the agent/model sees a Windows Temp path and then cannot read it from a WSL-backed session.

I do not think #25944 is necessarily the root bug. The underlying mismatch looks older: UserInput::LocalImage is read with direct filesystem IO (std::fs::read(&path)), so a Windows drive path like C:\Users\... is interpreted by the WSL/Linux app-server as a Linux path and fails with No such file or directory, even though the same file exists at /mnt/c/Users/<user>/AppData/Local/Temp/....

There is also a branch that looks like the intended fix direction:

origin/fix/windows-wsl-view-image-path-27552
c180a79a68 Map Windows attachment paths for WSL view_image

That patch adds Windows-drive-path to WSL mount-path normalization (C:\... / C:/... -> /mnt/c/...) before path resolution under WSL. I did not find a public PR for that branch yet.

Suggested framing: #25944 likely made the latent Windows/WSL path mismatch visible to users in June; the product fix should normalize Desktop-supplied Windows attachment paths before WSL prompt-image/view_image file IO, or pass pasted images as actual image bytes/data URLs instead of a host-runtime-specific temp path.

Temporary local workaround for WSL users until this is fixed upstream:

If the Windows temp image still exists, create a Linux-visible alias for the exact Windows path string inside the Codex working directory / active CODEX_HOME. The failure mode is that WSL tries to read the literal path string C:\Users\<user>\AppData\Local\Temp\codex-clipboard-<uuid>.png; if that literal filename resolves to the real /mnt/c/... file, current local-image reads can succeed.

Example from WSL, adapting username and image id:

cd ~/.codex  # or the active CODEX_HOME used by Desktop
ln -s "/mnt/c/Users/<user>/AppData/Local/Temp/codex-clipboard-<uuid>.png" \
  "C:\Users\<user>\AppData\Local\Temp\codex-clipboard-<uuid>.png"

For repeated pastes, the same idea can be automated by watching Windows Temp for codex-clipboard-*.png and creating these literal-path symlinks in the active Codex home.

This is only a bridge workaround. It depends on the Windows temp file still existing and on the app-server resolving the relative local-image path from a directory where that literal symlink is visible. The real product fix should still normalize Desktop-supplied Windows attachment paths before WSL file IO, or pass pasted images as actual image bytes/data URLs instead of host-runtime-specific temp paths.

I’m seeing this on Windows with Codex running through WSL.

The Codex app reports pasted screenshots as Windows temp paths like:
C:\Users\Higi\AppData\Local\Temp\codex-clipboard-....png

Sometimes the app-side image loader says that path cannot be read, but the file is still available from inside WSL through the mounted Windows drive:
/mnt/c/Users/Higi/AppData/Local/Temp/codex-clipboard-....png

Our current workaround is to document this explicitly in AGENTS.md: when an image path from the Windows app fails, the agent should automatically translate C:\... to /mnt/c/... and inspect the image from there. We also check /tmp/codex-remote-attachments and recent codex-clipboard-*.png files if needed.
So the user does not need to resend or rewrite the path; the agent can read the image by resolving the Windows path through WSL.

Title:
Codex Desktop Windows + WSL: image previews and generated images are not visible, and WSL agent cannot reliably control host Chrome/browser

Environment:

• Codex Desktop on Windows
• Workspace inside WSL: /root/pycharm/dify_wsl
• Windows path form seen by Codex: \\wsl.localhost\Ubuntu-24.04\...
• WSL distro: Ubuntu 24.04
• Browser available in WSL: /snap/bin/chromium
• gh is not installed in WSL

Issue 1: image visibility / path bridge
When I attach or reference screenshots under WSL paths, Codex often reports:
Codex could not read the local image at \\wsl.localhost\Ubuntu-24.04\...: No such file or directory.

This happened for files such as:
\\wsl.localhost\Ubuntu-24.04\root\pycharm\dify_wsl\docs\ai\本体\stream_chat\img_3.png

The same class of problem also affects images generated through Codex images/image generation: the assistant may produce or reference an image, but the Codex Desktop UI does not render it reliably for the user.

Expected:

• Codex Desktop should pass image attachments/generated images as actual image inputs/outputs.
• Windows UNC paths, WSL /mnt/c/... paths, and Linux workspace paths should be normalized consistently.
• If image rendering is unsupported in this mode, the UI should show a clear actionable message.

Actual:

• The agent and UI appear to disagree about the file path / filesystem view.
• The image may exist from one side, but Codex cannot read or render it from another side.

Issue 2: WSL agent cannot reliably control host browser
When running Codex from a WSL workspace, controlling the host browser / Chrome is unreliable or unavailable. Browser automation may require manual Chromium launch inside WSL with --remote-debugging-port=9222; the normal host-browser integration does not work consistently.

Expected:

• Codex Desktop on Windows + WSL should either bridge browser control to the Windows host browser reliably, or clearly document that WSL agent mode does not support this and provide a recommended workaround.

Actual:

• Browser control from WSL frequently fails or is unavailable.
• This blocks visual/UI verification workflows in WSL projects.

Same issue on Windows 11 + WSL mode — still reproduces after full reinstall, clean WSL distro rebuild, and app-local state reset.

Symptom (identical to OP): pasting an image into Codex Desktop fails with:

Codex could not read the local image at C:\Users\<user>\AppData\Local\Temp\codex-clipboard-<uuid>.png: No such file or directory (os error 2)
The file does exist and is fully readable from inside WSL at the translated path:

/mnt/c/Users/<user>/AppData/Local/Temp/codex-clipboard-<uuid>.png
So the app appears to hand the WSL-side agent the raw Windows path without translating it to /mnt/c/....

Concrete example:

Failing path given to agent: C:\Users\<user>\AppData\Local\Temp\codex-clipboard-2e04c2d7-3fdc-4ddd-86d2-cab3cb5afe20.png
Same file readable in WSL: /mnt/c/Users/<user>/AppData/Local/Temp/codex-clipboard-2e04c2d7-3fdc-4ddd-86d2-cab3cb5afe20.png — valid PNG, 70×98, inspectable by the agent when pointed at the translated path manually.
Environment:

Windows 11 Home (10.0.26200)
Codex Desktop package 26.623.11225.0, runtime component 26.630.12135
WSL 2.6.1.0, distro Ubuntu 26.04 (WSL 2)
runCodexInWindowsSubsystemForLinux = true
CODEX_HOME redirected to a D: drive path (junction from %USERPROFILE%\.codex kept for compatibility) — mentioning for completeness, but see below: elimination testing suggests this is not the cause.
What I ruled out (bug reproduced identically after each of these):

Reinstalled Codex Desktop.
Clean rebuilt the Ubuntu WSL distro from scratch (new BasePath, fresh rootfs).
Backup-first reset of all Codex app-local state (%LOCALAPPDATA%\Packages\OpenAI.Codex_* and %LOCALAPPDATA%\OpenAI\Codex), without touching durable Codex home.
Verified the clipboard PNG is present in Windows Temp every time and readable via /mnt/c/... from the same distro the agent runs in.
This makes local corruption (app cache, WSL distro, profile state) very unlikely. The failure looks like a missing Windows→WSL path conversion in the attachment handoff layer.

Impact note: this fails in a way the agent can't always see — the image is silently unavailable, so if the user doesn't notice the error, the agent proceeds without the image and can go down the wrong path. A workaround that helps me meanwhile: an AGENTS.md rule + small script that has the agent look up recent codex-clipboard-*.png files under /mnt/c/Users/<user>/AppData/Local/Temp/ and read them via the translated path.

Happy to provide logs or run a debug build if useful.

I've also reproduced this issue in Codex Desktop (Windows + WSL), including with attachments originating from Windows Phone Link, so I'm sharing details to reinforce the diagnosis already discussed here (especially @MisterRound's analysis of Windows → WSL path normalization).

Environment:

• Codex Desktop/MSIX: OpenAI.Codex 26.707.9981.0
• Runtime reported in logs: 26.707.72221
• Codex CLI: 0.144.2
• Windows 11, build 10.0.26200.8875, x64
• WSL: 2.7.10, Ubuntu 24.04, WSL kernel 6.18.33.2
• Agent configured to run in WSL2

Reproduction 1 (pasted screenshot):
I pasted a screenshot directly into Codex Desktop. The generated path was something like C:\Users\<windows-user>\AppData\Local\Temp\attachment.png. The WSL agent tried to open that path directly and failed with "No such file or directory (os error 2)", even though the file still existed on the Windows side. After I manually copied/translated the file to a staging path such as /run/user/<uid>/codex-attachments/..., the agent was able to open the image normally.

Reproduction 2 (Windows Phone Link attachment):
The same failure pattern occurred with images originating from Windows Phone Link, with paths like C:\Users\<windows-user>\AppData\Local\Packages\Microsoft.YourPhone_.../TempState\medias\.... Again, the WSL agent could not open the Windows path directly, but succeeded after manual translation to a WSL-accessible path.

This is consistent with the diagnosis already raised in this issue: the path provided by the Windows side of Desktop is not translated into a path the WSL environment can resolve before being passed to view_image/file read.

I don't consider this resolved: I did not find a merged public PR for the fix/windows-wsl-view-image-path-27552 branch mentioned by @MisterRound, and my reproductions occurred after that fix proposal had already been identified.

As a suggestion (already aligned with prior discussion in this issue): automatically stage the attachment at a path the agent's environment (WSL) can resolve, or use a stable attachment identifier and translate the path according to the consuming environment, validating that the file is readable before announcing it to the agent. I'd also suggest adding a test covering paste/attach on Windows Desktop with the WSL agent confirming it can read the file via view_image.

Additional reproduction on Windows + WSL, July 16, 2026:

• Codex Desktop package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
• Windows host: Windows 11 x64
• WSL app-server mode is enabled: runCodexInWindowsSubsystemForLinux = true
• Workspace is running through WSL

When I paste a screenshot into Codex Desktop, the message exposes a Windows Temp path such as:

C:\Users\weihao\AppData\Local\Temp\codex-clipboard-9753540e-1e60-42c7-b602-36e9411d35d8.png

The file exists on Windows and is accessible from WSL through the corresponding path:

/mnt/c/Users/weihao/AppData/Local/Temp/codex-clipboard-9753540e-1e60-42c7-b602-36e9411d35d8.png

The WSL shell can confirm the file and copy it into /home/weihao/.codex/tmp/, but the image-reading path still reports:

Codex could not read the local image ... No such file or directory

This indicates the Desktop -> WSL attachment handoff or the image-tool filesystem view is not applying the Windows-to-WSL path mapping consistently. The issue is reproducible even when the source PNG is present and readable from both Windows and WSL. No private screenshot was uploaded in this report.

Additional reproduction on July 16, 2026: this is not limited to clipboard or %TEMP% attachments.

Environment:

• Codex App on Windows
• Agent Environment: WSL
• WSL-native execution enabled:

``toml
[desktop]
runCodexInWindowsSubsystemForLinux = true
``

I copied an image to the Windows Desktop and dragged it into Codex. The app passed the raw host path to the WSL agent:

C:\Users\user\Desktop\665aa1f611acce14b5a332962d0accb4.jpg

The attachment read failed with:

Codex could not read the local image at
C:\Users\user\Desktop\665aa1f611acce14b5a332962d0accb4.jpg:
No such file or directory (os error 2)

However, the same file was present and readable from the same WSL instance after the normal drive mapping:

/mnt/c/Users/suer/Desktop/665aa1f611acce14b5a332962d0accb4.jpg

Reading the mapped path succeeded, so the file is not missing and this is not a Temp-file cleanup race. It appears that the Desktop → WSL attachment handoff is passing a Windows path verbatim instead of normalizing it for the consuming runtime.

This broadens the issue from pasted screenshots to normal drag-and-drop local files as well. The fix should either:

1. translate Windows drive paths (C:\... / C:/...) to the corresponding WSL mount path before attachment/image file I/O; or
2. stage/upload attachment bytes to a location shared with the WSL agent, rather than using a host-specific path string.

A regression test should cover drag-dropping a Windows local image into a WSL-backed Codex session and verify that the agent can consume it without manual path translation.