Skip to content

Codex Desktop WSL-native mode hides Chrome bridge tool and passes Windows attachment paths to Linux agent #31049

Open
Open
Codex Desktop WSL-native mode hides Chrome bridge tool and passes Windows attachment paths to Linux agent#31049
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@SYU8384
SYU8384
opened on Jul 3, 2026

What issue are you seeing?

After enabling WSL-native Codex execution with:

[desktop]
runCodexInWindowsSubsystemForLinux = true

Codex correctly runs shell commands inside WSL and avoids repeated Windows wsl.exe launches. However, two Windows-side integrations regress:

  1. The normal Chrome bridge becomes unavailable in WSL-native sessions.
  2. Local image attachments are passed to the Linux agent as raw Windows paths like C:\Users\...\AppData\Local\Temp\...png, causing No such file or directory.

Environment

  • Codex Desktop version: 26.623.13972.0 / plugin runtime observed as 26.623.101652
  • Platform: Windows 11 + WSL2 Ubuntu
  • Shell after switch: /bin/bash
  • Codex app server after switch: 
    /mnt/c/Users/zhuqi/.codex/bin/wsl/.../codex app-server --analytics-default-enabled

Reproduction steps

  1. On Windows with WSL2 Ubuntu, configure:

    [desktop]
runCodexInWindowsSubsystemForLinux = true

  2. Restart Codex Desktop.

  3. Open a WSL-backed Codex session.

  4. Ask Codex to use the normal Chrome bridge against an existing signed-in Chrome tab.

  5. Observe that the Chrome plugin instructions require mcp__node_repl__js, but tool discovery does not expose that tool.

  6. Attach or paste an image from Windows clipboard.

  7. Observe Codex receives a path like:

    C:\Users\zhuqi\AppData\Local\Temp\codex-clipboard-....png

    and fails to read it inside WSL.

Expected behavior

  • In WSL-native Codex mode, WSL repo commands should run inside Linux.
  • The trusted Chrome bridge should still be available, or Codex should provide a supported Windows-side bridge path.
  • Windows local attachment paths should be translated before being handed to a Linux agent, e.g.: 
    C:\Users\zhuqi\AppData\Local\Temp\file.png
    to: 
    /mnt/c/Users/zhuqi/AppData/Local/Temp/file.png

Actual behavior

  • mcp__node_repl__js is not exposed in the WSL-native session, so Chrome bridge setup cannot proceed.
  • The Chrome plugin files exist and node_repl.exe is running, but the required tool is unavailable to the agent.
  • Windows attachment paths fail inside Linux until manually translated to /mnt/c/....

Evidence collected

  • Chrome plugin enabled in Windows config:

    [plugins."chrome@openai-bundled"]
enabled = true

  • WSL-native mode enabled:

    runCodexInWindowsSubsystemForLinux = true

  • node_repl.exe observed running under the WSL-backed Codex app server.

  • Chrome plugin files present:

    /mnt/c/Users/zhuqi/.codex/plugins/cache/openai-bundled/chrome/26.623.101652/scripts/browser-client.mjs

  • Tool discovery did not expose mcp__node_repl__js; it returned unrelated tools.

  • Image attachments exist at translated paths and are valid PNGs, but raw C:\... paths fail inside WSL:

    /mnt/c/Users/zhuqi/AppData/Local/Temp/codex-clipboard-ccc83cfc-7979-44f7-a959-6f6407fb09c2.png
/mnt/c/Users/zhuqi/AppData/Local/Temp/codex-clipboard-389777c7-8916-4676-ae60-b769833139dd.png

  • Screenshots from the affected session show:

    • Chrome bridge unavailable after WSL-native/interruption state.
    • Local image path read failure from raw C:\... path.

Why this matters

Users on Windows + WSL need WSL-native mode to avoid WSL instability from many repeated Windows-side wsl.exe launches. But switching to WSL-native mode currently breaks workflows that depend on signed-in Chrome state, browser verification, clipboard images, and Windows attachment paths.

The current workaround is painful: switch between WSL-native mode for repo work and Windows-hosted mode for Chrome/attachment-heavy work, restarting Codex each time.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    browser
    on Jul 3, 2026

  2. github-actions commented on Jul 3, 2026

    @github-actions
    github-actionsBot
    on Jul 3, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. StreamVi commented on Aug 25, 2026

    @StreamVi
    StreamVi
    on Aug 25, 2026 – with ChatGPT Codex Connector

    Reproduced this in Codex Desktop on Windows with a WSL-backed workspace (August 25, 2026), multiple times in the same task.

    Observed behavior:

    1. A PNG pasted from the Windows clipboard was passed to the agent only as a raw Windows path:
      C:\Users\<redacted>\AppData\Local\Temp\codex-clipboard-<uuid>.png
    2. The attachment reader immediately reported:
      No such file or directory (os error 2)
    3. The same file was then checked manually at the translated WSL path:
      /mnt/c/Users/<redacted>/AppData/Local/Temp/codex-clipboard-<uuid>.png
    4. The file existed there, and the image could be opened successfully when the translated /mnt/c/... path was supplied explicitly.

    This confirms that, at least in this reproduction, the screenshot was not missing or already deleted. The failure was specifically caused by passing the unconverted Windows path to the WSL/Linux-side image reader.

    Expected behavior: Codex Desktop should either attach the image bytes directly or translate Windows attachment paths to their WSL mount paths before invoking image/file tools.

  4. oneone1995 commented on Aug 29, 2026

    @oneone1995
    oneone1995
    on Aug 29, 2026 – with ChatGPT Codex Connector

    Still reproducible on Codex Desktop 26.825.5331.0 on Windows with WSL execution enabled.

    Reproduction:

    1. Open a WSL-backed task.
    2. Paste an image from the Windows clipboard.
    3. Codex passes a path like C:\Users\<redacted>\AppData\Local\Temp\codex-clipboard-<uuid>.png.
    4. Image ingestion fails with No such file or directory (os error 2).

    Reproduced twice with newly pasted images. Expected behavior: Codex should either transfer the attachment bytes directly or translate the path for WSL and retain the temporary file until ingestion completes.

  5. Lili679280 commented on Sep 9, 2026

    @Lili679280
    Lili679280
    on Sep 9, 2026

    Attachment-path follow-up: Windows package 26.901.6511.0 + Fedora WSL

    Adding newer-package evidence and a broader set of affected attachment entry points to the attachment part of this issue.

    Environment: Windows x64 Codex Desktop with the local agent running in WSL2 / Fedora Linux 44. The screenshot-path failure was observed during use of earlier desktop builds; on 2026-09-09, the original Store package 26.901.6511.0 still contains the unnormalized paths, and its bundled implementations reproduce the problem in focused tests. This is the AppX package version, not an About-dialog version.

    User-visible reproduction

    1. Enable local WSL execution and open a WSL-backed task.
    2. Paste a screenshot from the Windows clipboard, or drag a Windows file into the task.
    3. The attachment is represented by a Windows path, for example:
    C:\Users\<user>\AppData\Local\Temp\codex-clipboard-<id>.png
    1. The Linux-side reader cannot resolve that path, although the same file is available at:
    /mnt/c/Users/<user>/AppData/Local/Temp/codex-clipboard-<id>.png

    The application should translate structured attachment paths for the destination execution host before ingestion, or transfer the image/file content directly.

    Affected boundaries found in the stock bundle

    • Clipboard/appshot temporary image persistence writes successfully to Windows, then returns the raw Windows path.
    • Electron drag-and-drop obtains a raw Windows path through webUtils.getPathForFile.
    • The add-context-file handler constructs path and fsPath from the original input.
    • Files opened with the desktop application are also turned into descriptors containing the original path.

    The clipboard and drag paths explain the observed failure; the other two were identified and checked at the bundled-code level, rather than by claiming every UI flow was manually reproduced.

    Local validation and suggested fix

    A diagnostic patch in a private copy normalizes these structured paths using the existing execution-host converters. It leaves the actual Windows temp-file write location unchanged. Drag/drop normalization goes through a main-process IPC handler that checks the trusted sender. For add-context-file, normalization follows the destination host, not the global local-WSL setting, so remote Windows tasks keep native Windows paths.

    Six focused attachment tests exercise/check the bundled code. On the stock 26.901.6511.0 package, five fail for the missing normalization while the native-Windows/pathless-input test passes; all six pass with the local correction. Coverage includes Unicode and filename case, drive and WSL UNC paths, pathless input, untrusted IPC, clipboard write-vs-return paths, and local-vs-remote destination hosts.

    This is evidence for an upstream fix, not an official patch or a claim of complete UI verification on 26.901.6511.0. The original Store bundle was not modified. All example user paths are anonymized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions