[BUG] Windows image paste (Alt+V) fails in Claude Code but works in Codex CLI on the same terminal/clipboard

Additional, stronger isolation — same Claude Code binary, different terminal host, different behavior:

On the exact same machine with Claude Code v2.1.201:

• In cmd.exe (conhost), Alt+V pastes the clipboard image successfully.
• In Windows Terminal, Alt+V with the same clipboard contents reports "no image in clipboard" and fails.

Nothing changes except the terminal host — no different tool, no different clipboard, no different image. This points the problem specifically at how Claude Code reads keyboard/clipboard input under the Windows Terminal host (ConPTY) versus the classic conhost, rather than at the clipboard format or the image itself.

So on Windows there are now two independent controls isolating the bug to Claude Code's Windows input/clipboard path:

1. Codex CLI pastes fine in the same Windows Terminal where Claude Code fails.
2. Claude Code itself pastes fine in cmd/conhost but fails in Windows Terminal.

Root cause found. The terminal host (Windows Terminal vs conhost) was never the real variable — the working directory Claude Code is launched from is. I've confirmed this by reverse-engineering the v2.1.201 binary and with live counter-tests.

TL;DR

When claude is launched with its cwd set to C:\Windows\System32 (or C:\Windows, or even C:\), every internal spawn of powershell is silently blocked by Claude Code's own "unsafe location" guard, and the failure is misreported as "No image found in clipboard". Launch the same binary from any normal directory (e.g. %USERPROFILE%) in the same Windows Terminal, and Alt+V pastes images fine.

The defect

Internal spawns go through a safe-spawn wrapper (minified Gv) that resolves bare command names via where.exe and then rejects any candidate that is "in an unsafe location (current directory)". The check (minified Hdn) is:

if (dirname(candidate) === cwd || candidate.startsWith(cwd + sep)) return true; // unsafe

The second clause is a whole-subtree prefix match, not a "same directory" check. So with cwd = C:\Windows\System32, the only where.exe candidate —

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

— starts with c:\windows\system32\ and is rejected as "unsafe". Gv throws Command 'powershell' not found or is in an unsafe location (current directory), the clipboard-read function (minified bPe) swallows the exception in its catch and returns null, and the UI reports "No image found in clipboard" — masking a spawn-policy failure as an empty clipboard.

Evidence

1. The OS/PowerShell layer is healthy under Windows Terminal. In the exact environment (child of the failing claude.exe process, WT_SESSION set), I manually ran the verbatim commands Claude Code uses:

• checkImage: powershell -NoProfile -NonInteractive -Sta -Command "Add-Type -AssemblyName System.Windows.Forms; if (-not [System.Windows.Forms.Clipboard]::ContainsImage()) { exit 1 }" → exit 0 (~200 ms)
• saveImage (GetImage + Save PNG to %TEMP%\claude_cli_latest_screenshot.png) → exit 0, PNG written.

1. Simulating the resolution logic (run where.exe powershell, apply the Hdn checks):

• cwd = C:\Windows\System32 → the single candidate is rejected → resolution returns null.
• cwd = C:\Users\<user> → same candidate accepted.

1. Live counter-test: in the same Windows Terminal, starting claude from C:\Users\<user> makes Alt+V image paste work; starting it from System32 reproduces the failure.

Why the original WT-vs-conhost differential was misleading

My Windows Terminal had "startingDirectory": null in profiles.defaults, and elevated launches then land in C:\Windows\System32 — so claude inherited cwd = System32 there. The cmd/conhost control test happened to start in %USERPROFILE%. Same binary, same clipboard; the hidden variable was the cwd all along. (Codex CLI worked in the same WT simply because it has no such cwd guard.)

Impact & suggested fix

• Broader than image paste: with cwd under C:\/C:\Windows/C:\Windows\System32, any internal direct spawn of a System32 binary is blocked by the same guard.
• Suggested fixes:

1. Restrict the unsafe-cwd check to dirname(candidate) === cwd (the actual CWD-hijack threat model), or exempt trusted system directories (%SystemRoot% subtree resolved via where.exe is not attacker-controlled).
2. Don't mask spawn failures as "No image found in clipboard" — surface the real error (there are already distinct telemetry keys not_found / clipboard_read_failed internally; the user-facing message should distinguish them too).

Workaround for anyone hitting this: don't launch claude from C:\Windows\System32 (e.g. an elevated shell's default directory) — cd to your project or home directory first, and/or set Windows Terminal's startingDirectory.

Confirming the same issue on my setup:

Environment:

• Windows 10 Enterprise (19045)
• Windows Terminal + PowerShell 7
• Claude Code v2.1.205
• Native Windows (not WSL)

Symptoms:

• Clipboard image paste (Ctrl+V) does not attach the image — no error shown, just nothing happens.
• Drag-and-drop of files into the input also does not work anymore (used to insert the file path as text).
• Both used to work in a previous version; can't pin down exactly which update broke it.

Same clipboard contents work fine in other apps (Paint/Word), so it does look like it's isolated to Claude Code's Windows clipboard/drag-drop handling, consistent with what's reported here and in #26679 / #32791.

Can confirm Alt+V works for me — successfully pasted a Win+Shift+S screenshot into Claude Code CLI.

Environment:

• Windows 11 Home
• Windows Terminal (confirmed via $env:WT_SESSION being set)
• Claude Code v2.1.231

This is a newer Claude Code version than the one reported here (v2.1.201), so this may have been fixed in between. Might be worth checking if this is still reproducible on the latest version.