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

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

26.608.12217

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 x64

What issue are you seeing?

I am using Codex Desktop on Windows with a WSL/Linux workspace:

/home/slee/Codex_Hermes

Image attachments appear to be broken across the Desktop → WSL agent bridge.

When I paste or attach an image into Codex Desktop, the app saves it to Windows Temp, for example:

C:\Users\SLee\AppData\Local\Temp\codex-clipboard-0e3ab3dd-2534-4d64-99da-ae5e7308bd9d.png

PowerShell confirms the file exists:

Test-Path "C:\Users\SLee\AppData\Local\Temp\codex-clipboard-0e3ab3dd-2534-4d64-99da-ae5e7308bd9d.png"
=> True

WSL also confirms the same file is accessible through:

/mnt/c/Users/SLee/AppData/Local/Temp/codex-clipboard-0e3ab3dd-2534-4d64-99da-ae5e7308bd9d.png

The WSL command succeeds:

ls -l "/mnt/c/Users/SLee/AppData/Local/Temp/codex-clipboard-0e3ab3dd-2534-4d64-99da-ae5e7308bd9d.png"

Codex shell can also confirm the file exists and can copy it, but the image viewing tool cannot access the copied image from /tmp or /home/slee/Codex_Hermes. Node/Python attempts hit EPERM or appear to run in a different filesystem/sandbox view.

This means the image file exists and is readable from Windows and WSL, but Codex Desktop does not pass it as actual image input, and Codex tools do not appear to share a consistent filesystem view.

I already submitted in-app feedback with session logs.

Feedback ID:
019eb56c-f97e-78e0-89b7-fea3134e5c88

Expected:
Image attachments should be passed as actual image input to the agent, or the Windows Temp path should be consistently mapped to the WSL-accessible path and visible to view_image.

Actual:
The agent receives only a Windows Temp file path, and view_image cannot access the image even when shell can confirm the file exists.

What steps can reproduce the bug?

Feedback ID: 019eb56c-f97e-78e0-89b7-f1. Open Codex Desktop on Windows.
2. Use a WSL/Linux workspace, for example:

/home/slee/Codex_Hermes

Paste or attach a PNG image into the Codex conversation.
Ask Codex to describe the image.
Codex reports that it only sees a Windows Temp file path and cannot access the image.
Confirm in PowerShell that the Temp PNG exists:

Test-Path "C:\Users\SLee\AppData\Local\Temp\codex-clipboard-0e3ab3dd-2534-4d64-99da-ae5e7308bd9d.png"
=> True
Confirm in WSL that the corresponding /mnt/c path exists:

ls -l "/mnt/c/Users/SLee/AppData/Local/Temp/codex-clipboard-0e3ab3dd-2534-4d64-99da-ae5e7308bd9d.png"
Ask Codex to copy the image into /tmp or /home/slee/Codex_Hermes.
Codex shell can see the copied file, but view_image cannot access it.
Node/Python attempts hit EPERM or appear to run in a different filesystem/sandbox view.

In-app feedback was submitted with session logs enabled.

Feedback ID:
019eb56c-f97e-78e0-89b7-fea3134e5c88

ea3134e5c88

What is the expected behavior?

No response

Additional information

No response

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

Image attachments visible to model are not available as local files for agent workflows #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//AppData/Local/Temp/codex-clipboard-.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//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//AppData/Local/Temp/ and read them via the translated path.

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

@MisterRound

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 July 16, 2026: this is not limited to clipboard or %TEMP% attachments.

Environment:

Codex App on Windows
Agent Environment: WSL

WSL-native execution enabled:

[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:

translate Windows drive paths (C:\... / C:/...) to the corresponding WSL mount path before attachment/image file I/O; or
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.

Additional reproduction on 2026-07-22. This confirms that the path-mapping problem is not limited to C: or %LOCALAPPDATA%\Temp; a clipboard image on another mounted Windows drive is affected as well.

Environment:

Codex Desktop on Windows with the agent running in WSL
WSL-side codex --version: codex-cli 0.145.0-alpha.27

Pasting a clipboard image produced:

Codex could not read the local image at
E:\Cache\Windows\Temp\codex-clipboard-a3050e6e-5118-4ada-b6e1-d922746ac77d.png:
No such file or directory (os error 2)

The source file had not been deleted. From the same WSL environment it existed at the normal drive mapping:

/mnt/e/Cache/Windows/Temp/codex-clipboard-a3050e6e-5118-4ada-b6e1-d922746ac77d.png

Observed evidence:

File size: 72,519 bytes
The mapped /mnt/e/... path was readable from WSL
The image-reading tool successfully opened and decoded the PNG when given the mapped WSL path

This rules out temp-file cleanup and image corruption for this reproduction. The Windows side passed the raw E:\... path to the WSL-side image reader without translating it to /mnt/e/....

The fix should normalize arbitrary Windows drive paths generically (X:\... or X:/... to /mnt/x/...) before WSL-side attachment/image I/O, or stage attachment bytes in a runtime-neutral shared location.

Additional reproduction on 2026-07-30 with Codex Desktop app/runtime 26.721.81911 and a native WSL workspace.

This case involved a generated screenshot rather than an incoming clipboard attachment:

Windows Chrome was launched headlessly from the WSL-backed task.
Chrome successfully wrote a 142,470-byte PNG into a Windows-backed Codex visualization directory.
Both PowerShell and WSL ls confirmed the exact file existed and was readable.
The image-inspection tool nevertheless reported that the same absolute path did not exist.
Copying the PNG into the native WSL worktree did not make it visible to the image-inspection tool during that session.
In a later Codex session, the image-inspection tool could open the original unchanged PNG at the same path.

That last control suggests a per-session snapshot/namespace propagation problem in addition to basic Windows-path translation. The file was valid and persistent; shell visibility and image-tool visibility disagreed only in the producing session.

Expected: a PNG generated during a WSL-backed Desktop task should become immediately readable by the image tool, whether stored in the declared visualization directory or copied into the writable workspace.

I reproduced this and confirmed that the failure is caused by missing Windows-to-WSL path conversion.

Codex Desktop passes the attachment as:

C:/Users/<user>/AppData/Local/Temp/<file>.png

Inside WSL, this is treated as a relative path and resolved as:

<working-directory>/C:/Users/<user>/AppData/Local/Temp/<file>.png

which fails with No such file or directory.

The same file can be read successfully after converting the path to:

/mnt/c/Users/<user>/AppData/Local/Temp/<file>.png

I also verified that the file still existed and was a valid PNG, so this was not caused by expiration, permissions, corruption, or Windows short-path handling.

Codex Desktop should normalize Windows drive paths before passing attachments to WSL, or copy the attachment into a WSL-accessible temporary directory.

Additional reproduction on 2026-08-05 with Codex Desktop 26.727.6591.0, Windows 11, and a native Ubuntu 22.04 WSL workspace.

Two separate screenshots pasted in successive messages in the same task were exposed only as Windows temp paths:

C:\\Users\\<user>\\AppData\\Local\\Temp\\codex-clipboard-<uuid>.png

In both cases the attachment reader immediately reported:

No such file or directory (os error 2)

Checking the corresponding /mnt/c/Users/<user>/AppData/Local/Temp/... path from the WSL task also found that the file was already absent. This reproduction therefore suggests a temp-file lifetime / attachment-staging race in addition to the already documented Windows-to-WSL path normalization problem.

Expected: Desktop should pass image bytes as attachment input, or copy the file to a stable task-scoped location shared with the WSL agent before exposing it to tools. The shared copy should remain available for the lifetime of the task. A regression test should cover two clipboard images pasted into successive messages of one WSL-backed Desktop task.

I can confirm this still reproduces on Codex Desktop 26.803.5235.0 with Codex CLI 0.147.0, Windows 11, and WSL2 Ubuntu.

Pasted images are passed to the WSL agent as raw Windows temporary paths such as C:\\Users\\<user>\\AppData\\Local\\Temp\\codex-clipboard-<uuid>.png, then fail with No such file or directory (os error 2). I confirmed it in two separate sessions.

This significantly disrupts normal WSL-based development because screenshots cannot be used reliably and manually saving or translating every image is not a practical workflow.

I can reproduce the same class of attachment handoff failure outside Windows/WSL, using the experimental Remote TUI across two Linux hosts.

Environment/topology:

Local Linux machine runs codex --remote ws://127.0.0.1:4500
An SSH local-forwarding tunnel maps local port 4500 to a Synology NAS
The NAS runs codex app-server --listen ws://127.0.0.1:4500
NAS/server Codex CLI version: 0.147.0

When I paste a clipboard screenshot into the local Remote TUI, the client first stages it under its local /tmp. The remote NAS-side agent then receives or tries to use that local temporary path, but the file has already been removed and is not present in the NAS filesystem. Codex reports that the temporary image was deleted before it could be read.

This suggests the issue is broader than Windows-to-WSL path normalization: a host-specific LocalImage path is crossing an app-server boundary without transferring/staging the image bytes in storage visible to the remote app-server. Temp-file lifetime can also race with the remote read.

Expected behavior: for a remote app-server connection, the TUI should send the image as inline data (or upload/stage it into a stable server-visible attachment location) and keep it available for the turn/session lifetime. At minimum, Remote TUI should reject cross-host local image paste with an actionable message instead of forwarding an unusable temporary path.

Current workaround is to pipe/save the clipboard image over SSH into a NAS path and reference that NAS-side path manually.

Still reproducing on Codex Desktop 26.825.6671.0 with WSL 2.7.12.0. The file exists under /mnt/c, and view_image works once the Windows path is translated manually.

Commit c180a79a68 appears to implement that mapping. Its branch is now 3,943 commits behind main, with no public PR.

Could you rebase and publish that fix, or point us to its replacement? Happy to test a current build.

Reproduced on 2026-09-08 with Codex Desktop 26.901.6511.0, bundled Linux codex-cli 0.153.4, Windows + WSL2. I also tested a workaround at the initial attachment ingestion boundary, rather than making the model retry view_image.

The Desktop-supplied localImage.path is a raw C:\Users\<user>\AppData\Local\Temp\codex-clipboard-<uuid>.png. Initial ingestion reports No such file or directory (os error 2). The unchanged image exists and opens when its WSL path is supplied. This reproduction does not depend on a missing/deleted Temp file.

Controlled test against the installed binary

A small WSL-side stdio adapter modifies only structured localImage paths in turn/start and turn/steer, using /usr/bin/wslpath -a -u before forwarding the request. The original Codex binary still performs image reading, validation, encoding, and model-input serialization. Text, other input types, RPC metadata, and permission settings are preserved. No AGENTS.md instructions or model recovery tool calls are involved.

I exercised the real bundled app-server with an isolated CODEX_HOME, a loopback mock Responses endpoint, and synthetic PNGs. No account credentials or remote model service were used. Two consecutive turns each supplied two images, including Windows backslash and forward-slash paths and filenames with spaces/Unicode.

Actual HTTP model input	Turn 1	Turn 2, including earlier image history
Unmodified path handoff	0 images + read-error text	0 images + read-error text
Structured input adapted before ingestion	2 `input_image` parts, no read-error text	4 `input_image` parts, no read-error text

The test decodes the serialized image data URLs and checks their image signatures. It also passed through the optional launcher's complete wrapper entry point, which selects the unmodified bundled runtime by SHA-256. Nine focused unit tests cover start/steer, multiple inputs, mapping failures, native/unchanged paths, text/RPC/permission preservation, and a real WSL path round-trip.

The essential boundary is:

# In a WSL-side stdio adapter, before forwarding to Codex:
if request.get("method") in ("turn/start", "turn/steer"):
    for item in request.get("params", {}).get("input", []):
        if item.get("type") == "localImage" and is_windows_absolute_path(item["path"]):
            item["path"] = subprocess.run(
                ["/usr/bin/wslpath", "-a", "-u", item["path"]],
                check=True, capture_output=True, text=True, timeout=5,
            ).stdout.removesuffix("\n")

This is an illustrative excerpt; the tested adapter additionally validates message shapes, passes unrelated traffic through, retains an attachment if conversion fails, and forwards process signals/stdio without modifying the server's responses.

Fix direction and limits

Please cover initial localImage ingestion, not only tool-path resolution. Commit c180a79a68974292868e628133b00cf273bcc567 changes TurnContext::resolve_path, but its diff alone does not establish that initial attachment reads are covered. The experiment above directly exercises that ingestion path.

Ideally the owning client transfers image bytes or stages attachments in stable server-visible storage. When translating local WSL paths, use the selected distro's actual mapping instead of assuming every drive is under /mnt/<drive>. Preserve attachment lifetime until ingestion completes.

Validation limits: full Desktop UI launch/paste verification through the optional launcher is pending an app restart; the installed app-server serialization path is verified. Live steering, non-default mount layouts, multiple distros, and restricted sandbox combinations have not been tested end to end. This path-only workaround does not address deleted Temp files or cross-host file transfer.

Additional current-build reproduction on 2026-09-19:

Codex Desktop package: 26.915.4065.0
Host: Windows 11
Agent execution: WSL-backed Desktop task

A clipboard PNG was announced to the task with a raw Windows path and initial ingestion reported:

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)

I tested the exact same attachment immediately afterward:

The source PNG still existed under Windows Temp and was 13,463 bytes.
Supplying the backslash form C:\\Users\\... to view_image failed because it was resolved beneath the WSL task cwd as a relative path.
Supplying the forward-slash form C:/Users/... failed the same way.
Supplying the translated path /mnt/c/Users/<user>/AppData/Local/Temp/codex-clipboard-<uuid>.png loaded and decoded the unchanged image successfully.

This reproduction rules out Temp cleanup, image corruption, and permissions. The failure is still the unnormalized Windows path crossing into the WSL-side attachment/image reader. It also confirms that changing backslashes to forward slashes is insufficient because C:/... remains relative syntax on Linux.

Expected: normalize structured attachment paths for the destination execution host before initial ingestion, or transfer/stage attachment bytes in runtime-visible storage. A regression test should verify the initial pasted-image read in a Windows Desktop + WSL task, not only a later manual view_image retry.

It would be nice if WSL User could give images like screenshots to Codex and I hope openAI will no longer ignore this issue.
I found a working agent-side workaround for Codex Desktop on Windows with a WSL workspace.
The screenshot exists at its original Windows path, but view_image fails inside its filesystem sandbox. Instead of converting the path to /mnt/c/... or copying the file into /tmp, the agent can read the original C:... path directly through powershell.exe.
The image is resized in memory, encoded as Base64, and returned directly as image content:

$src = "C:\Users\<USER>\AppData\Local\Temp\codex-clipboard-....png"

Add-Type -AssemblyName System.Drawing

$img = [System.Drawing.Image]::FromFile($src)
$width = 1600
$height = [int]($img.Height * $width / $img.Width)

$bmp = New-Object System.Drawing.Bitmap $width, $height
$graphics = [System.Drawing.Graphics]::FromImage($bmp)
$graphics.DrawImage($img, 0, 0, $width, $height)

$stream = New-Object System.IO.MemoryStream
$bmp.Save($stream, [System.Drawing.Imaging.ImageFormat]::Jpeg)

[Convert]::ToBase64String($stream.ToArray())

$graphics.Dispose()
$bmp.Dispose()
$img.Dispose()
$stream.Dispose()

The agent can then render the command output directly:
image("data:image/jpeg;base64," + result.output.trim());
This successfully bypasses view_image, the WSL path translation problem, and the failing filesystem sandbox.
Notes:

The original Windows path must be used.
Copying the image to /tmp or the WSL workspace did not help.
Depending on the permission profile, running powershell.exe may require approval.
This is a read-only workaround and does not modify the source image.
It does not fix the underlying Desktop-to-WSL bridge bug, but it makes screenshots usable until an upstream fix is available.

Still reproducing on Codex Desktop 26.924.2738.0 (bundled app-server 0.158.0-alpha.2.1, Windows 10.0.26200 x64, WSL2 Ubuntu 26.04, %TEMP% on D:). This adds two things that I don't think are covered here yet.

1. Queued follow-ups are a third ingestion boundary, and there the bug is a hard error.

If the pasted image is submitted while a turn is running (follow-up behavior = Queue), thread/queue/add rejects it:

Request failed durationMs=14 method=thread/queue/add
error={"code":-32600,"message":"local queued attachment is invalid: No such file or directory (os error 2)"}

The queue snapshots attachments at enqueue time (ext/queue/src/service.rs prepare_queued_user_input → snapshot_local_user_input in protocol/src/local_media.rs). An unreadable path therefore fails the request instead of becoming the local_media_error_placeholder text you get with turn/start / turn/steer.

I believe the queued-image reports in #23277 (2026-09-11, 09-13, 09-23) are this issue. Those reporters couldn't capture the submitted path. In my case the same paste was then sent as turn/steer a few seconds later, and the rollout records the path the app sent:

{"type": "local_image", "path": "D:\\<temp>\\codex-clipboard-<uuid>.png"}

Core replaced it with Codex could not read the local image at D:\<temp>\...: No such file or directory (os error 2). The file was fine: the agent read it with view_image at /mnt/d/<temp>/codex-clipboard-<uuid>.png in the same turn. Across my WSL sessions, all 3 pasted images (2026-09-20, 09-22, 09-27) carried a Windows drive path and none reached the model.

So a fix or adapter that only covers turn/start and turn/steer (as in the experiment above) would still leave queued follow-ups broken. thread/queue/add needs the same treatment.

2. The client-side gate that sends the raw path.

In the shipped main bundle (minified), composer image attachments are mapped by a helper equivalent to:

function toImageInput(src, { localPath, isRemoteHost = false } = {}) {
  if (!isRemoteHost && localPath) return { type: "localImage", path: localPath };
  if (/^data:image\//i.test(src)) return { type: "image", url: src };
  ...
}

It is called with isRemoteHost: hostId !== "local". In WSL mode the host id is local, so the Windows localPath from persistImageFileToTemp (join(os.tmpdir(), "codex-clipboard-<uuid>.<ext>")) goes through unchanged. The data-URL branch that remote hosts already use would avoid the problem. Another fix is to translate the path for the WSL app-server before building the localImage item. Doing it at this single point would cover start, steer and queue.

I’m seeing the same Windows Desktop + WSL image attachment failure.

My setup

Windows 11

Codex Desktop: 26.928.2636.0 (please confirm in Help → About)

Ubuntu on WSL 2

Codex CLI in WSL: 0.159.3

What happens
I paste an image into a Codex Desktop chat and ask Codex to inspect it. Codex says it cannot read:

C:\Users\roblo\AppData\Local\Temp\codex-clipboard-c530d7b9-56d6-428d-a171-526c9196acd2.png

The reported error is: No such file or directory (os error 2).

Checks
WSL itself works, and Codex CLI in WSL successfully ran pwd, uname -a, and ls on my workspace after I selected a supported model. So basic WSL startup and project-folder access work; the failure is with the Desktop image attachment handoff.

Expected
The pasted image should reach the agent as image input, or Desktop should provide a path that exists in the agent’s environment.

This happened when I [sent the message directly / queued it — keep the applicable option].

Still reproducible on October 2, 2026, with Windows Desktop package 26.930.2377.0 and bundled WSL Core 0.159.0-alpha.12.1: the same-turn rollout retains a raw C:\Users\...\codex-clipboard-<uuid>.png path in the UserMessage image entry, while the corresponding model-facing response_item contains only text, including the read-error placeholder, and no input_image; the unchanged PNG still exists and opens successfully through its mapped /mnt/c/... path, ruling out Temp cleanup or image corruption for this occurrence.

This corroborates the ingestion failure and client-side path handling already documented above rather than introducing a new root-cause claim; could a maintainer confirm whether a complete fix is being tracked for initial image ingestion, alongside the tool-path and queued-input boundaries discussed here?

I can still reproduce a related image attachment issue in Codex Desktop on Windows with WSL as the agent environment.

Error:
local queued attachment is invalid: No such file or directory (os error 2)

Observed behavior:

Codex was executing a task when I attempted to send a follow-up message containing an image.
The attachment failed to submit with the error above.
The issue is intermittent; image attachments sometimes work correctly.
I am using the Windows Codex Desktop application with WSL as the agent environment.

This may be related to the Windows-to-WSL image path handling or queued attachment lifecycle discussed in this issue.

I have attached a screenshot showing the error.

Could the maintainers confirm whether queued image attachments and initial image ingestion share the same underlying issue?

Navigation Menu

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

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?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

1 remaining item

Controlled test against the installed binary

Fix direction and limits

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

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?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jun 11, 2026

lansman commented on Jun 20, 2026

adamilardi commented on Jun 21, 2026

MisterRound commented on Jun 22, 2026

MisterRound commented on Jun 22, 2026

higi commented on Jun 29, 2026

dtgz-sudo commented on Jun 30, 2026

arvydas-hub commented on Jul 3, 2026

gilmarvitor commented on Jul 16, 2026

1 remaining item

LIEGU0317 commented on Jul 16, 2026

CissiBot commented on Jul 22, 2026

khukhunaishvili commented on Jul 30, 2026

JM-FRANK commented on Aug 2, 2026

StreamVi commented on Aug 4, 2026

mura0319 commented on Aug 10, 2026

Juddd commented on Aug 18, 2026

moinerus commented on Sep 1, 2026

guwidoe commented on Sep 8, 2026

Controlled test against the installed binary

Fix direction and limits

MisterRound commented on Sep 19, 2026

Mathasyu commented on Sep 25, 2026

CissiBot commented on Sep 27, 2026

rob-4x4 commented on Oct 1, 2026

GoldenSection0618 commented on Oct 2, 2026

dtgz-sudo commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions