[BUG] Windows: screenshot clipboard paste fails ("No image found in clipboard") although the image is present in PNG+Bitmap formats

Summary

On Windows, pasting a screenshot/image into the Claude Code prompt fails with No image found in clipboard. Use alt+v to paste images, even though the image is genuinely present on the Windows clipboard in standard formats (PNG + Bitmap). The clipboard read inside Claude Code returns "no image" while a standard Win32/.NET clipboard read of the exact same clipboard state returns the image instantly. This makes the screenshot → conversation workflow unusable on Windows.

This is a heavily-used workflow for me: dropping a screenshot straight into the chat is the fastest way to give the AI visual context for a UI/visual bug. An image is worth a thousand words — trying to describe a visual bug in text is dramatically slower and less accurate than just showing it. I relied on exactly this (screenshot → straight into the conversation) constantly in GitHub Copilot CLI, and losing it in Claude Code is a real productivity hit.

Environment

• OS: Windows 10 Pro 19045
• Terminal: Windows Terminal (PowerShell 7 profile)
• Claude Code: v2.1.175
• Screenshot source: Win+Shift+S (Windows Snip), which places the image on the clipboard

Steps to reproduce

1. Take a screenshot with Win+Shift+S (image goes to the Windows clipboard).
2. In the Claude Code prompt, press Alt+V (the documented Windows image-paste key — Ctrl+V is consumed by Windows Terminal's own Terminal.PasteFromClipboard binding and never reaches Claude Code).
3. Result: No image found in clipboard. Use alt+v to paste images — no image is attached.
4. Expected: the image is attached to the prompt (e.g. an [Image #1] placeholder appears).

Key evidence: the image IS on the clipboard

This is the important part — it is not an empty/wrong-format clipboard, and it is not caused by running elevated. Immediately after the snip, reading the same clipboard from Windows PowerShell 5.1 on an STA thread returns the image and its formats:

powershell.exe -STA -NoProfile -Command {
  Add-Type -AssemblyName System.Windows.Forms,System.Drawing
  ([System.Windows.Forms.Clipboard]::GetDataObject()).GetFormats() -join ', '
  $img = Get-Clipboard -Format Image
  if ($img) { "IMAGE: $($img.Width) x $($img.Height)" }
}

Output:

Formats on clipboard: Preferred DropEffect, System.Drawing.Bitmap, Bitmap, PNG
IMAGE: 819 x 391

So the clipboard carries the image in both Bitmap and a registered PNG clipboard format, and standard clipboard APIs read it with no problem. Claude Code's image reader nonetheless reports "no image found". I verified this read works the same whether the reading process is elevated (admin) or not, so integrity level / "run as administrator" is not the cause — the bug is in Claude Code's clipboard image-read path on Windows.

Why I think this is a clipboard-reader bug (not key handling)

Alt+V clearly reaches Claude Code (it prints the "No image found" message), so the keybinding is fine. The failure is in the function that reads the image from the Windows clipboard returning null/empty while the image is demonstrably present. This matches the pattern in the related macOS report below, where the reader function returned null.

Related (closed but unresolved across all 3 platforms)

• #9301 — Windows 11, exact same message ("No image found in clipboard. Use alt+v"), opened Oct 2025, closed not planned. Reporter says it never worked.
• #17130 — Ubuntu, "No image found in clipboard", a regression (worked in an earlier version), closed.
• #29776 — macOS, Ctrl+V "fails silently / No image found", closed not planned; reporter root-caused the clipboard image reader returning null.

The same symptom on Windows, Linux, and macOS — each closed individually — suggests the cross-platform clipboard image-read path needs a real fix rather than per-platform triage. I'm re-raising with concrete clipboard-format evidence and a clear, common use case to ask for reconsideration.

Proposed solutions

1. Read the PNG registered clipboard format directly on Windows. As shown above, Win+Shift+S (and most Windows screenshot tools) place a ready-to-use PNG on the clipboard under the registered format name "PNG", in addition to CF_BITMAP/CF_DIB. Reading those bytes is the most robust path and avoids any DIB-to-PNG conversion. Falling back to CF_DIBV5/CF_DIB/CF_BITMAP covers the rest.
2. Don't depend on terminal Ctrl+V passthrough. Windows Terminal binds Ctrl+V to its own paste; keep Alt+V as the Windows image-paste key (it already reaches the app), and fix the underlying clipboard read.
3. Surface the real error instead of a silent "No image found". Log/why the read failed (format mismatch, STA/threading, buffer size, API exception). The macOS report (#29776) traced its failure to a buffer/maxBuffer issue that was being silently swallowed — Windows likely has an analogous swallowed failure.
4. In the error message, point users to the working fallback (@ <path-to-image-file>), which does work today, so people aren't stuck.

Workaround I'm using meanwhile

Save the screenshot to a file and reference it with @<path> (which is also how image input works in GitHub Copilot CLI via @). It works, but it's several extra steps versus a direct paste, which is why the direct clipboard paste matters for fast visual-bug reporting.