[BUG] Alt+V on Windows wipes clipboard contents when image paste fails (data loss, not just no-op)

Summary

On Windows, when the user presses Alt+V to paste an image from the clipboard and Claude Code reports "clipboard is empty / no image found", the clipboard payload is also destroyed in the process. This is silent data loss, not just a failed paste — subsequent paste attempts in any other application (Paint, browsers, etc.) find an empty clipboard.

This is distinct from #56792 (which documents the read failure itself). The read failure has been reported for months across multiple versions; the additional finding here is that the failure branch is mutating the clipboard.

Environment

• Claude Code CLI version: 2.1.150 (also reproduced on 2.1.131 and 2.1.146)
• OS: Windows 11 Pro, build 10.0.26100
• Terminal: Windows Terminal / PowerShell 7+
• Session: console session (same Windows session as the user's Explorer/Paint — verified via query session -> SessionId 14 for both)

Steps to reproduce

1. Copy an image to the clipboard. Any source works — Win+Shift+S (Snipping Tool), copying an image from a browser, Ctrl+C on an image in Explorer, etc.

1. Verify Windows sees the image (run from the same Windows session as the Claude Code process):

``powershell
Add-Type -AssemblyName System.Windows.Forms
[System.Windows.Forms.Clipboard]::ContainsImage()
# -> True
([System.Windows.Forms.Clipboard]::GetDataObject()).GetFormats()
# -> System.Drawing.Bitmap, Bitmap, PNG, CanUploadToCloudClipboard, CanIncludeInClipboardHistory
``

1. Switch focus to the Claude Code terminal window. Press Alt+V.

Observed: status line / banner reports something equivalent to "no image found in clipboard".

1. Without copying anything else, immediately re-run the check from step 2:

``
ContainsImage = False
Formats: System.String, UnicodeText, Text, Locale, OEMText
``
All image-related formats are gone. Switching to Paint and pressing Ctrl+V also yields nothing.

Expected behavior

A clipboard read operation that fails should leave the clipboard untouched. The user's clipboard payload is owned by whoever wrote it; a consumer must not call EmptyClipboard or otherwise mutate the data.

Actual behavior

The image (and all formats associated with it) is removed from the clipboard during the failed Alt+V handling. Effect on the user is indistinguishable from OpenClipboard(hwnd); EmptyClipboard(); CloseClipboard(); being called on the failure path.

Suspected root cause

Without access to the binary it's a guess, but the symptom is consistent with the clipboard-read code path doing one of:

• Calling EmptyClipboard() inside the failure branch (legal only for the owner who just called OpenClipboard, but should never be called by a consumer that's only trying to read).
• Re-SetClipboardData-ing only a text payload (status message? error string?) which implicitly evicts every other format.

A trace with API Monitor / Detours on OpenClipboard, EmptyClipboard, SetClipboardData, CloseClipboard from the Claude Code process around an Alt+V keystroke would confirm.

Impact

• Users who rely on Alt+V to paste screenshots (a documented workaround across multiple blog posts and earlier issues) lose clipboard contents on every failed attempt.
• The loss is silent — the banner says "no image", which most users read as "nothing happened". They only discover the loss when they try to paste somewhere else.
• If the user had copied something high-value before the screenshot — long text, code snippet, a multi-line command — that payload is also gone if it was the previous clipboard owner, because the destruction is unconditional.

Workaround

Avoid Alt+V entirely while this is open. Either:

1. Drag the image file from Explorer into the terminal (inserts an absolute path Claude Code resolves).
2. Save the screenshot to disk first (Win+PrtScn writes to %USERPROFILE%\OneDrive\Pictures\Screenshots\ or local equivalent), then drag the file.

Related

• #56792 — Alt+V image paste reports "clipboard is empty" on Windows 11 CLI v2.1.131 (this report documents an additional symptom on top of that bug)
• #29776, #22068, #9301, #9124 — earlier Windows clipboard-read failures