Windows Desktop + WSL2: inline Visualize silently fails because /mnt/c/... is normalized as a Windows root path

[Hugo-Polloli]

What version of the Codex App are you using?

Codex Desktop for Windows.

• Release shown in logs: 26.818.31338
• Microsoft Store package: OpenAI.Codex_26.818.3698.0_x64__2p2nqsd0c76g0
• Bundled Visualize plugin: 1.0.22

What subscription do you have?

Not relevant to this local Desktop path-handling reproduction.

What platform is your computer?

Windows 11 x64 with the Codex agent configured to run in WSL2 Ubuntu.

WSL kernel:

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64

What issue are you seeing?

An inline visualization created by a WSL2-backed Codex task does not render in Codex Desktop. The visualization placeholder disappears without a chart or a useful file-read error.

The agent receives a thread-scoped visualization directory on the Windows filesystem through its WSL mount:

/mnt/c/Users/<windows-user>/.codex/visualizations/YYYY/MM/DD/<thread-id>

The agent writes a valid HTML fragment there and the final response references its absolute WSL path:

visualize{"path":"/mnt/c/Users/<windows-user>/.codex/visualizations/YYYY/MM/DD/<thread-id>/minimal.html","mode":"wide","title":"Minimal visualization"}

The file exists. wslpath -w resolves it to the expected native path:

C:\Users\<windows-user>\.codex\visualizations\YYYY\MM\DD\<thread-id>\minimal.html

The observed fragment was 34,069 bytes, below the 5 MB limit. Its JavaScript parsed successfully and the fragment had none of the disallowed document wrappers or escaped-markup artifacts. The content layer is therefore not the failing layer.

Root-cause evidence

The packaged Desktop visualization read service receives the path, obtains the execution host's platform path implementation, normalizes the supplied path, performs containment checks, and then calls the execution host's stat and readFile methods.

With Windows path semantics, the relevant transformation is:

input:      /mnt/c/Users/<windows-user>/.codex/visualizations/.../minimal.html
normalized: \mnt\c\Users\<windows-user>\.codex\visualizations\...\minimal.html

Node's Windows path implementation considers the input absolute. Its relative-path containment check also succeeds against a matching /mnt/c/... writable root. The read then reaches the native Windows filesystem with \mnt\c\..., which resolves on the current drive as the nonexistent mixed path C:\mnt\c\... instead of C:\Users\....

This isolates the defect to the Desktop path boundary: a WSL absolute path is validated with Windows path semantics but is not converted to a Windows path before native file access. The Desktop log identifies the renderer platform as Windows and the task environment as WSL-disabled for Windows-native browser features:

browser_use_availability_resolved available=false platform=Windows reason=wsl-disabled release=26.818.31338

The visualization read failure itself is not logged with the requested or resolved path, which makes the UI failure silent.

Steps to reproduce

1. Use Codex Desktop on Windows 11.
2. Configure the agent environment to use WSL2 Ubuntu.
3. Start a task whose visualization writable root is exposed to WSL under /mnt/c/Users/<windows-user>/.codex/visualizations/....
4. Ask Codex to create a minimal inline visualization with the bundled Visualize plugin.
5. Confirm the generated fragment exists with stat.
6. Confirm wslpath -w <absolute-fragment-path> resolves to C:\Users\<windows-user>\....
7. Let the response emit the inline visualization reference containing the absolute /mnt/c/... path.
8. Observe that the visualization does not render and no actionable error is shown.

Expected behavior

Codex Desktop should preserve the filesystem authority associated with the path.

For an agent-created /mnt/<drive>/... path, Desktop should do one of the following before native Windows file access:

• convert it to the corresponding Windows path, such as C:\Users\...;
• delegate stat and readFile to the WSL execution host that created the path;
• materialize the fragment as a renderer asset through an explicit host-neutral transfer boundary.

If the read fails, the inline placeholder should remain visible and show the requested path, resolved path, execution host, and file-read error.

Actual behavior

The app silently drops the inline visualization. The file remains present at the correct WSL and Windows-equivalent location.

Related issues

• Visualize skill saves files to workspace path, but renderer reads from ~/.codex #32054 reports the same silent visualization disappearance when the renderer resolves a valid fragment under the wrong .codex/visualizations owner. That report is macOS and concerns workspace-relative versus home-relative resolution.
• Codex Desktop Windows+WSL resolves bundled plugin cache as invalid C:\mnt\c path #24268 records the same Windows + WSL mixed-path result, C:\mnt\c\..., in bundled plugin reconciliation.
• Windows Desktop + WSL workspace: node_repl rejects /mnt/c sandboxCwd before Chrome/browser bootstrap #29413 and Browser control rejects file:///mnt/c/... sandboxCwd in WSL agent mode for Windows-hosted folders #33560 record /mnt/c/... reaching native Windows browser runtimes without conversion.
• Codex Desktop Windows+WSL creates in-app browser WebView despite wsl-disabled and spams git-repo-watcher EISDIR #32183 contains another observed C:\mnt\c\... access failure and groups related Windows + WSL path-boundary defects.

This appears related to those issues but is not an exact duplicate. It affects the inline visualization file reader and reproduces with the absolute path supplied by the visualization protocol.

Privacy note

User names, thread identifiers, project names, and visualization contents are redacted. A minimal fragment and sanitized log excerpt can be supplied if needed.

[github-actions]

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

• Switching Codex from WSL to Windows-native breaks existing chats, rewrites /mnt/d paths as C:\mnt\d, and loses project associations #38781

Powered by Codex Action

[StreamVi]

Reproduced again on a newer Windows build. The issue is still present.

Environment:

• Codex Desktop release: 26.818.41509
• Microsoft Store package: OpenAI.Codex 26.818.5229.0
• Bundled Visualize plugin: 1.0.22
• Windows 11 x64, agent running in WSL2 Ubuntu
• WSL kernel: 6.6.114.1-microsoft-standard-WSL2

Observed behavior:

1. A valid thread-scoped fragment was written to:

   /mnt/c/Users/<windows-user>/.codex/visualizations/YYYY/MM/DD/<thread-id>/agent-step-settings.html
   

2. The response emitted the normal absolute-path Visualize reference.

3. The UI first showed Error: Invalid visualization read request.

4. The fragment was simplified to static markup (no script or network access), validated again, and re-emitted.

5. The visualization still did not appear.

6. A new versioned filename (agent-step-settings-v2.html) was then created to rule out a stale-path/cache problem and emitted in a new response; it also did not appear.

Content-side controls:

• Original simplified fragment: 16,316 bytes
• Versioned fragment: 16,847 bytes
• UTF-8 HTML fragment with no doctype, html, head, or body wrapper
• No fetch, XHR, WebSocket, external resources, or JavaScript after simplification
• Bundled visualize/scripts/render.py successfully produced standalone output
• The rendered output displayed correctly in headless Chrome at 736 px

Additional diagnostic detail:

At the timestamps where the inline reference was processed, Desktop logged fs/readDirectory, fs/getMetadata, and fs/readFile responses with errorCode=null. No actionable visualization exception or requested/resolved path was logged. The renderer log only showed repeated ResizeObserver loop completed with undelivered notifications messages afterward.

This confirms the user-visible failure remains on 26.818.41509 / package 26.818.5229.0. The successful fs/readFile entries may also indicate that, in this newer build, at least one failing path reaches or passes the file-read stage and then fails later in the inline rendering pipeline.

User name, thread ID, and visualization contents are intentionally redacted.

[SenlerBot]

Reproduced the same failure in Codex Desktop on Windows with a WSL workspace.

• Visualization file was created under /mnt/c/Users/<user>/.codex/visualizations/YYYY/MM/DD/<thread-id>/tariff-recovery-center.html.
• The inline card showed the exact error: Error: Invalid visualization read request.
• Re-emitting the visualization reference did not help.
• The artifact itself is valid and small (about 21 KB): a static HTML fragment with no <script>, no document wrapper, and no network requests.
• The same file renders successfully when opened directly in local Chrome, and a PNG rendered from it is correct.

This is consistent with the reported /mnt/c/... path being resolved with Windows path semantics instead of being translated from WSL to the corresponding Windows path.

[SenlerBot]

Additional reproduction on 2026-09-01:

• Codex Desktop on Windows with the task running in a WSL workspace.
• Codex CLI: 0.130.0-alpha.5.
• Bundled Visualize plugin: 1.0.23.
• The fragment was written under the provided thread-scoped root using its WSL path:
  /mnt/c/Users/<redacted>/.codex/visualizations/YYYY/MM/DD/<thread-id>/billing-planned-changes.html.
• The assistant emitted the documented visualize content reference with that exact absolute WSL path.
• The conversation did not display the visualization.
• The source fragment exists and is readable: 10,628 bytes.
• The bundled Visualize renderer successfully generated a standalone preview from the same fragment: 47,986 bytes.

This is consistent with the WSL-to-Windows path-boundary failure described in this issue rather than malformed visualization content. User name, thread ID, project details, and visualization contents are intentionally omitted.