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
-
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.
-
Verify Windows sees the image (run from the same Windows session as the Claude Code process):
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
-
Switch focus to the Claude Code terminal window. Press Alt+V.
Observed: status line / banner reports something equivalent to "no image found in clipboard".
-
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:
- Drag the image file from Explorer into the terminal (inserts an absolute path Claude Code resolves).
- Save the screenshot to disk first (Win+PrtScn writes to
%USERPROFILE%\OneDrive\Pictures\Screenshots\ or local equivalent), then drag the file.
Related
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
query session-> SessionId 14 for both)Steps to reproduce
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.
Verify Windows sees the image (run from the same Windows session as the Claude Code process):
Switch focus to the Claude Code terminal window. Press Alt+V.
Observed: status line / banner reports something equivalent to "no image found in clipboard".
Without copying anything else, immediately re-run the check from step 2:
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
EmptyClipboardor 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:
EmptyClipboard()inside the failure branch (legal only for the owner who just calledOpenClipboard, but should never be called by a consumer that's only trying to read).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,CloseClipboardfrom the Claude Code process around an Alt+V keystroke would confirm.Impact
Workaround
Avoid Alt+V entirely while this is open. Either:
%USERPROFILE%\OneDrive\Pictures\Screenshots\or local equivalent), then drag the file.Related