WSL image paste fallback fails when appendWindowsPath=false and Get-Clipboard returns null

[keisanmono]

Codex CLI version

codex-cli 0.131.0

Platform

WSL2 Debian on Windows 11, terminal: kitty / xterm-kitty.

My WSL config has Windows PATH appending disabled:

[interop]
appendWindowsPath = false

WSL_INTEROP is still set, and Windows .exe files are executable by absolute path, so this is not the same as WSL interop being disabled.

Issue

Pasting an image into the Codex TUI fails with:

Failed to paste image: no image on clipboard: The clipboard contents were not available in the requested format or the clipboard is empty.

The Windows clipboard does contain an image. Verified from the same WSL environment by launching Windows PowerShell 5.1 via absolute path:

/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe

Using:

Add-Type -AssemblyName System.Windows.Forms
[Windows.Forms.Clipboard]::ContainsImage()
$img = [Windows.Forms.Clipboard]::GetImage()

Output showed:

ContainsImage=True
ImageSize=813x520

The Linux/X11 clipboard side only exposes text targets:

TIMESTAMP
TARGETS
UTF8_STRING
TEXT

and xclip -selection clipboard -t image/png -o reports that image/png is not available.

Root cause hypothesis

codex-rs/tui/src/clipboard_paste.rs has a WSL fallback in try_dump_windows_clipboard_image(), but it fails in this environment for two independent reasons:

1. The fallback only tries command names:

["powershell.exe", "pwsh", "powershell"]

Those rely on PATH. With [interop] appendWindowsPath = false, none of them resolve, even though Windows PowerShell is executable by absolute path at:

/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe

2. The fallback script uses:

Get-Clipboard -Format Image

In this environment that returns $null, while [Windows.Forms.Clipboard]::GetImage() succeeds for the same clipboard image.

Suggested fix

For the WSL image paste fallback:

1. After PATH-based candidates fail, try common absolute Windows PowerShell locations under WSL, for example:

/mnt/<drive>/Windows/System32/WindowsPowerShell/v1.0/powershell.exe
/mnt/<drive>/Program Files/PowerShell/7/pwsh.exe

Ideally derive the mount root via wslpath -u 'C:\' or mounted drives instead of hard-coding only /mnt/c.

2. Prefer the WinForms clipboard API, while keeping the existing cmdlet as a fallback:

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
Add-Type -AssemblyName System.Windows.Forms
Add-Type -AssemblyName System.Drawing

$img = $null
if ([Windows.Forms.Clipboard]::ContainsImage()) {
    $img = [Windows.Forms.Clipboard]::GetImage()
}
if ($null -eq $img) {
    $img = Get-Clipboard -Format Image -ErrorAction SilentlyContinue
}
if ($null -eq $img) {
    exit 1
}

$p = [System.IO.Path]::Combine(
    [System.IO.Path]::GetTempPath(),
    [System.IO.Path]::GetRandomFileName() + ".png"
)
$img.Save($p, [System.Drawing.Imaging.ImageFormat]::Png)
Write-Output $p

3. When invoking pwsh, pass -STA; PowerShell Core defaults to MTA and WinForms clipboard APIs require STA. Windows PowerShell 5.1 is STA by default.

4. If the fallback fails, include diagnostic detail in the final error, e.g. whether no PowerShell executable was found or the script exited non-zero. Currently the user only sees the original arboard error, so it is hard to tell that the WSL fallback was attempted.

Related

Possibly related to #7766, #7599, #15612, and #19143, but this report is specifically about the appendWindowsPath=false + Get-Clipboard -Format Image failure path on Codex CLI 0.131.0.