›_ Codex Issues
Codex Issues / #34947

WSL + VS Code image paste: Ctrl+Alt+V hint is unusable and PowerShell fallback requires Windows PATH

Open 💬 0 comments Opened Jul 23, 2026 by luyucheng-dev

What version of Codex CLI is running?

codex-cli 0.145.0 (latest according to codex doctor --json at the time of testing)

Environment

  • Windows 11, build 26200.8875
  • WSL 2.7.10.0, kernel 6.18.33.2-2
  • Ubuntu 20.04.6 LTS under WSL2
  • VS Code 1.130.0 (1b6a188127eeaf9194f945eb6eb89a657e93c54c), integrated terminal with TERM_PROGRAM=vscode and TERM=xterm-256color
  • Windows Terminal with the same WSL distribution, used as a control
  • Windows PowerShell 5.1.26100.8875
  • WSL interop is enabled (WSL_INTEROP is present), but automatic Windows PATH injection is intentionally disabled:
[interop]
appendWindowsPath = false

[boot]
systemd = true

Summary

Pasting a Windows clipboard image into the Codex TUI from WSL has two independent compatibility problems in this setup:

  1. The shortcut overlay recommends Ctrl+Alt+V for every WSL terminal, but VS Code's Windows-hosted xterm.js treats Ctrl+Alt as a potential AltGr/third-level shift and does not emit this key combination into the PTY. Codex never receives the shortcut. Alt+V works.
  2. Once Alt+V reaches Codex, the WSL clipboard fallback can invoke Windows PowerShell only by command name. With appendWindowsPath=false, no PowerShell command is on the Linux PATH, so the fallback fails even though WSL interop is enabled and Windows PowerShell is executable by absolute path.

Together, these make the advertised image-paste flow fail in a common Windows 11 + WSL2 + VS Code terminal setup. They are separate implementation issues, but they affect the same end-to-end user action, so I am reporting the complete tested workflow here. Problem 2 is also tracked in #23611.

Problem 1: the WSL shortcut hint is not usable in VS Code Terminal

With the composer empty, pressing ? shows:

ctrl + alt + v to paste images

Controlled result:

| Terminal running the same WSL distribution | Ctrl+Alt+V | Alt+V |
| --- | --- | --- |
| VS Code integrated terminal | Does not reach the Codex TUI | Reaches the TUI |
| Windows Terminal | Reaches the TUI | Reaches the TUI |

Setting CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=0 did not change this matrix.

VS Code keyboard shortcut troubleshooting confirms that VS Code receives the complete chord and does not invoke a matching workbench command:

[KeybindingService]: | Resolving ctrl+alt+V
[KeybindingService]: \ From 1 keybinding entries, no when clauses matched the context.
[KeybindingService]: / Received keydown event - modifiers: [ctrl,alt], code: KeyV, keyCode: 86, key: v

The bundled xterm.js version is 6.1.0-beta.288 (8aab310366549d8d865bd8fc4bd509051f2bb2a1). Its keydown path returns early for a third-level shift, and on Windows that condition explicitly includes altKey && ctrlKey:

Codex already accepts either a Control- or Alt-modified V for image paste:

However, the shortcut overlay selects Ctrl+Alt+V based only on is_wsl:

Codex already has WSL + VS Code terminal detection for its keyboard-enhancement compatibility logic, so that detection could be factored/reused for the hint:

Suggested behavior:

  • WSL + VS Code Terminal: show Alt+V to paste images
  • Other WSL terminals: keep Ctrl+Alt+V if appropriate
  • Non-WSL: keep the existing behavior

Related but not identical: #11708 reports a generic Ctrl+V versus Alt+V description mismatch. This report is specifically about the WSL-only Ctrl+Alt+V hint and the reproducible VS Code/xterm.js AltGr path.

Problem 2: the WSL PowerShell fallback depends on Windows PATH injection

With appendWindowsPath=false, none of these resolve:

command -v powershell.exe
command -v pwsh
command -v powershell

Pressing Alt+V reaches Codex, but image paste fails with the original Linux clipboard error:

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

Launching Codex with only the Windows PowerShell directory added makes the same Windows clipboard image paste successfully:

PATH="$PATH:/mnt/c/Windows/System32/WindowsPowerShell/v1.0" codex

Invoking the same PowerShell executable by absolute path also confirms that Get-Clipboard -Format Image can read the Windows clipboard image in this environment. I do not reproduce the separate Get-Clipboard-returns-null behavior described in #23611.

The current fallback tries only PATH-resolved command names:

Suggested behavior: preserve the current PATH candidates, then, when running under WSL with interop enabled, try deterministic Windows PowerShell locations resolved to WSL paths (for example through wslpath) before giving up. This should not require enabling global Windows PATH injection or scanning the filesystem.

Expected behavior

For the tested setup:

  1. The TUI shortcut overlay should advertise a key combination that the active terminal can actually deliver (Alt+V for VS Code + WSL).
  2. With WSL interop enabled but appendWindowsPath=false, image paste should locate Windows PowerShell without requiring the user to modify the global WSL PATH.
  3. After both compatibility paths are applied, taking a Windows screenshot and pressing the advertised Alt+V in the VS Code WSL terminal should attach the image without extra startup flags.

These changes would leave the existing behavior for other terminals and non-WSL environments intact.

View original on GitHub ↗