Image paste (Ctrl+V) stopped working in Windows Terminal

same problem in v2.1.76

Still occurring in v2.1.84 with a slightly different behavior.

Environment:

• Claude Code: 2.1.84
• OS: Windows 11
• Terminal: Windows Terminal (WT_SESSION confirmed)
• Shell: PowerShell

Behavior:
Alt+V keybinding triggers correctly, but Claude Code responds with:
> "No image found in clipboard. Use alt+v to paste images."

Steps to reproduce:

1. Take a screenshot with Win+Shift+S (Snipping Tool)
2. Press Alt+V in Claude Code

Confirmed: The image IS in the clipboard — PowerShell can read it:
```powershell
Add-Type -AssemblyName System.Windows.Forms
[System.Windows.Forms.Clipboard]::GetImage() -ne $null
# Returns: True

Claude Code fails to detect the image despite it being accessible via System.Windows.Forms.Clipboard.

Workaround: None found. Saving to file and referencing by path works as alternative.

Same here
Claude Code v2.1.86

Same here. v2.1.86

Same for v2.1.89

same v2.1.89 - it's been months now

Same in v2.1.91

2.1.104
Same issue, Windows terminal Alt + v or Ctrl + v both are not working

Same issue here, "No image found in clipboard. Use alt+v to paste images."
Ctrl+V, Alt+V are not working

The solution is to delete Claude code and its folders completely from your system users/name/appdata and all folders and install native using PowerShell or a terminal command, not using npm from the official docs now is working with Alt + V i m on Windows 11

Same issue, Windows terminal Alt + v or Ctrl + v both are not working

Still reproducing on Windows 10 Home (10.0.19045) / Claude Code 2.1.113 / VS Code 1.116.0 integrated terminal. Ctrl+V image paste silently fails every time. Same configuration works on Linux (same account). No in-terminal workaround — only option is saving the image to disk and referencing the file path.

Working workaround for Windows: AutoHotkey + PowerShell bridge (single Ctrl+V press)

Tested on Claude Code 2.1.123, Windows 11 26200, PowerShell 7.6.1, Windows Terminal 1.24.10921. After
hitting this bug, I built a clipboard bridge that intercepts Ctrl+V in any terminal window, saves the
raw clipboard bitmap to a temp PNG, swaps the clipboard for the file as a FileDropList, then sends
Alt+V (the shortcut Claude Code accepts for file paste on Windows). Net result: Win+Shift+S then
Ctrl+V works in one press, exactly like on macOS.

Two small files, no admin required, no changes to Claude Code itself. Disabling it later is just
deleting the startup shortcut.

1. Install AutoHotkey v2

winget install --id AutoHotkey.AutoHotkey --silent

Heads-up: many AVs (Avast / AVG) flag AutoHotkey64.exe as IDP.Generic because it hooks the keyboard.
It is a long-known false positive for a legitimate open-source tool from autohotkey.com. Whitelist the
executable and the scripts folder, otherwise PowerShell calls from the script will be delayed by
minutes during heuristic scans.

1. Save the helper PowerShell script

Path: %USERPROFILE%\.claude\scripts\claude-paste-helper.ps1

param(
[Parameter(Mandatory=$true)][string]$OutPath
)

Add-Type -AssemblyName System.Windows.Forms
Add-Type -AssemblyName System.Drawing

$img = [System.Windows.Forms.Clipboard]::GetImage()
if ($null -eq $img) { exit 1 }

$dir = Split-Path -Parent $OutPath
if (-not (Test-Path $dir)) {
New-Item -ItemType Directory -Path $dir -Force | Out-Null
}

$img.Save($OutPath, [System.Drawing.Imaging.ImageFormat]::Png)
$img.Dispose()

$col = New-Object System.Collections.Specialized.StringCollection
[void]$col.Add($OutPath)
[System.Windows.Forms.Clipboard]::SetFileDropList($col)

exit 0

1. Save the AutoHotkey script

Path: %USERPROFILE%\.claude\scripts\claude-paste.ahk

#Requires AutoHotkey v2.0
#SingleInstance Force

global LogPath := EnvGet("USERPROFILE") . "\.claude\scripts\claude-paste.log"

Log("=== AHK started ===")
CleanupOldFiles()

#HotIf IsClaudeWindow()
~$^v::ClaudePaste()
#HotIf

IsClaudeWindow() {
try {
proc := WinGetProcessName("A")
terminals := ["claude.exe", "WindowsTerminal.exe", "wt.exe", "pwsh.exe", "powershell.exe",
"cmd.exe", "conhost.exe", "OpenConsole.exe", "alacritty.exe", "wezterm-gui.exe", "Hyper.exe",
"Tabby.exe", "mintty.exe", "Code.exe", "Cursor.exe"]
for term in terminals {
if (proc = term)
return true
}
title := WinGetTitle("A")
return InStr(title, "claude") > 0
} catch {
return false
}
}

ClaudePaste() {
hasImage := DllCall("IsClipboardFormatAvailable", "UInt", 8) ||
DllCall("IsClipboardFormatAvailable", "UInt", 2) || DllCall("IsClipboardFormatAvailable", "UInt", 17)
if !hasImage {
Log("Ctrl+V without image, pass-through")
return
}

tempDir := A_Temp . "\claude_paste"
if !DirExist(tempDir)
DirCreate(tempDir)

filePath := tempDir . "\img_" . FormatTime(, "yyyyMMdd_HHmmss") . "_" . A_TickCount . ".png"
helperPath := EnvGet("USERPROFILE") . "\.claude\scripts\claude-paste-helper.ps1"

cmd := 'powershell.exe -Sta -NoProfile -ExecutionPolicy Bypass -WindowStyle Hidden -File "' .
helperPath . '" -OutPath "' . filePath . '"'
exitCode := RunWait(cmd, , "Hide")

if (exitCode != 0 || !FileExist(filePath)) {
Log("Save failed (exit " . exitCode . ")")
Tip("Claude paste: save failed")
return
}

Log("Image saved: " . filePath)
Sleep 80
; Force-release Ctrl (user might still hold it), then send a clean Alt+V
SendInput "{LCtrl up}{RCtrl up}"
Sleep 30
SendInput "!v"
}

Tip(msg) {
ToolTip msg
SetTimer () => ToolTip(), -2500
}

Log(msg) {
try {
ts := FormatTime(, "yyyy-MM-dd HH:mm:ss")
FileAppend(ts . " | " . msg . "`n", LogPath)
}
}

CleanupOldFiles() {
tempDir := A_Temp . "\claude_paste"
if !DirExist(tempDir)
return
cutoff := DateAdd(A_Now, -7, "Days")
Loop Files, tempDir . "\*.png" {
if (A_LoopFileTimeModified < cutoff) {
try FileDelete A_LoopFileFullPath
}
}
}

1. Register autostart and launch

$ahkExe = "$env:LOCALAPPDATA\Programs\AutoHotkey\v2\AutoHotkey64.exe"
$script = "$env:USERPROFILE\.claude\scripts\claude-paste.ahk"
$startup = [Environment]::GetFolderPath('Startup')
$lnkPath = Join-Path $startup 'ClaudePasteBridge.lnk'

$wsh = New-Object -ComObject WScript.Shell
$lnk = $wsh.CreateShortcut($lnkPath)
$lnk.TargetPath = $ahkExe
$lnk.Arguments = ""$script""
$lnk.WorkingDirectory = Split-Path $script
$lnk.Save()

Start-Process -FilePath $ahkExe -ArgumentList ""$script""

Why this specific combination works

• ~$^v:: is required: ~ lets the original Ctrl+V also flow through (without it the hook silently

dropped the keystroke in Windows Terminal); $ prevents the SendInput !v from re-triggering the hotkey.

• Alt+V (not Ctrl+V) is the shortcut Claude Code listens to for FileDropList clipboard content on

Windows.

• {LCtrl up}{RCtrl up} before the Alt+V is critical: without it the user is often still pressing Ctrl

when AHK fires, and Claude sees Ctrl+Alt+V instead of plain Alt+V, which silently does nothing. Adding
the explicit Ctrl release made the workaround single-press instead of double-press.

• -Sta flag on PowerShell is required for the Clipboard.SetFileDropList COM call.

Uninstall (when Anthropic ships a real fix)

Get-Process AutoHotkey64 -ErrorAction SilentlyContinue | Stop-Process -Force
Remove-Item "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\ClaudePasteBridge.lnk"
Remove-Item "$env:USERPROFILE\.claude\scripts\claude-paste.ahk"
Remove-Item "$env:USERPROFILE\.claude\scripts\claude-paste-helper.ps1"
# Optional: winget uninstall AutoHotkey.AutoHotkey

Hope this saves time for others until the upstream fix lands.

On Windows 10, updating PowerShell to the latest version (v7) resolved the issue for me just a couple days ago. I installed it directly from the Microsoft Store, and since then, the clipboard error is gone, copying and pasting images now works without any problems.

works on PS 5 and PS 7 to use shortcut ALT + V + Q

better but still not as convenient if we just had CTRL + V

On native Windows Claude Code, Alt+V image paste showed:

"No image found in clipboard. Use alt+v to paste images"

even though Win+Shift+S had copied an image.

Root cause: powershell.exe was not in PATH. My default shell was PowerShell 7 (pwsh.exe), but Claude Code seems to rely on
Windows PowerShell 5.1 for reading image data from the clipboard.

Fix:

Add this to PATH:

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

Then restart the terminal. After where powershell resolved correctly, Alt+V image paste worked.

Suggestion: Claude Code should either call %SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe directly, or fall back
to pwsh.exe. The current error message is misleading because the clipboard does contain an image.

Then restart the terminal. After where powershell resolved correctly, Alt+V image paste worked.

Not working here.

Version v2.1.138 works - Version v.2.1.141 does not.

same for me :-(

Version v.2.1.143 does not work , neither ctrl+v or alt+v could paste image

Confirmed this is broken on v2.1.133, v2.1.138, and v2.1.143 when using claude code cli in windows terminal. How has this issue existed for so long without a fix?

Additional diagnostics — fault isolated to Claude Code's paste handler, not the OS clipboard

Hitting this on Windows 11. I ran a full diagnostic pass to isolate the layer that fails. Summary up front: the Windows clipboard and the exact PowerShell commands Claude Code uses are provably fine — the failure is entirely inside claude.exe's paste handler.

Environment

• Claude Code 2.1.143, native Windows installer (%USERPROFILE%\.local\bin\claude.exe)
• Windows 11 Pro 26200
• Windows PowerShell 5.1 (System32\WindowsPowerShell\v1.0\powershell.exe); PowerShell 7 / pwsh not installed
• Symptom: Alt+V image paste intermittently fails with No image found in clipboard, mostly with Snipping Tool (Win+Shift+S) snips

What Claude Code 2.1.143 actually runs (extracted from the binary)

The image-paste path spawns:

powershell -NoProfile -NonInteractive -Sta -Command
  "Add-Type -AssemblyName System.Windows.Forms; if (-not [System.Windows.Forms.Clipboard]::ContainsImage()) { exit 1 }"

and a separate spawn for the save:

powershell -NoProfile -NonInteractive -Sta -Command
  "Add-Type -AssemblyName System.Windows.Forms; $img = [System.Windows.Forms.Clipboard]::GetImage(); if ($null -eq $img) { exit 1 }; $img.Save(<path>, [System.Drawing.Imaging.ImageFormat]::Png)"

A non-zero exit from either produces No image found in clipboard. There is no retry.

Tests run

1. Live clipboard diagnostic immediately after a failed paste — ContainsImage: True, GetImage() returns OK 1839x1341 / 1011x945 from STA PowerShell. The OS clipboard holds a valid bitmap.
2. Verbatim invocation — Claude Code's exact powershell -NoProfile -NonInteractive -Sta -Command "..." for both CHECK and SAVE: exit 0, valid PNG written, whenever an image is on the clipboard.
3. Decay watcher — sampled the clipboard every 2 s for 40 s after a snip: ContainsImage: True / GetImage: OK 1368x652 for the entire 40 s, no decay.
4. Cold-spawn latency — 10 cold powershell spawns of the CHECK command: 155–171 ms, median 159 ms. No timeout-race window.

Hypotheses eliminated by measurement

• MTA apartment state — ruled out (-Sta is passed; pwsh not installed)
• -Sta / -NonInteractive flags — ruled out (verbatim call succeeds)
• Image larger than ~2000 px (#47063) — ruled out (fails on sub-1400 px images)
• Clipboard History / cloud-clipboard contention — ruled out (toggling it changed nothing)
• Delayed-render decay (source app exiting) — ruled out (image stable for 40 s)
• Cold-start timeout race — ruled out (check is a stable ~160 ms)

Conclusion

Every layer outside claude.exe is clean: the OS clipboard reliably holds the image, and Claude Code's own extracted PowerShell commands succeed 100 % when run directly. The failure occurs only when the paste is driven through Claude Code's TUI handler. The bug is in Claude Code's paste code path itself — likely how/when it spawns or sequences the check relative to the keypress — and there is no client-side or OS-side configuration that fixes it.

Happy to provide the diagnostic scripts or run further instrumented tests if a maintainer wants specific data.

Same on Antigravity IDE (Google's VS Code fork) integrated terminal, Windows 11 Pro 22621, Claude Code 2.1.143.

After an Antigravity auto-update wiped the previous IDE config and recreated a fresh one, Ctrl+V (and Alt+V) for image paste silently fail — same symptom @nthetrack documented above. The OS clipboard is fine: [System.Windows.Forms.Clipboard]::ContainsImage() returns True and GetImage() saves a valid PNG. Restoring terminal.integrated.defaultProfile.windows = "PowerShell" (Windows PowerShell 5.1) in settings.json did not help.

Workaround that fully unblocks the flow (PowerShell, no AutoHotkey / no admin):

function Save-ClipboardImage {
    param([string]$Path = "$env:TEMP\paste.png")
    Add-Type -AssemblyName System.Windows.Forms
    $img = [System.Windows.Forms.Clipboard]::GetImage()
    if ($img) {
        $img.Save($Path, [System.Drawing.Imaging.ImageFormat]::Png)
        Set-Clipboard -Value "@$Path"
        Write-Host "Saved: $Path. Clipboard now holds '@$Path' — paste in Claude Code with Ctrl+V."
    } else {
        Write-Host "No image in clipboard."
    }
}
Set-Alias cpimg Save-ClipboardImage -Force

Append to $PROFILE, then the flow is: Win+Shift+S → cpimg → Ctrl+V (pastes the @<path> string, which Claude Code consumes as an attached image via the @path syntax). Two extra keystrokes vs native Ctrl+V, works in any terminal (Git Bash, PowerShell, integrated VS Code/Antigravity), and doesn't depend on whichever code path inside claude.exe is regressed.

Reposting here in case anyone else lands on Antigravity (or any other VS Code fork) and finds that the usual "switch to PowerShell 5.1" answer doesn't move the needle.

Still broken in v2.1.146

Two follow-up notes since the diagnostic above

The format-detection hypothesis doesn't survive the verbatim test.

@jshaofa-ui's diagnosis in #59661 (cross-posted in #58923) — that the handler was narrowed to CF_BITMAP / image/png and misses CF_DIBV5 from Win+Shift+S — would predict that Claude Code's own extracted PowerShell would fail to detect Snipping Tool snips. It doesn't. Test #2 above runs the literal [System.Windows.Forms.Clipboard]::ContainsImage() / GetImage() calls Claude Code spawns, and they return True + a valid PNG specifically for Win+Shift+S snips — which is what every failed paste in this thread is reproducing on. WinForms.Clipboard covers CF_DIBV5 via the underlying OLE reader. The format gap isn't where the bug lives — the regression has to sit downstream of the PowerShell call (exit-code interpretation, stdout parsing between CHECK and SAVE, or spawn-vs-keystroke sequencing).

On the "first press fails, second succeeds" symptom in #59161.

Anecdotally my failures aren't uniformly random — the first Alt+V after a fresh snip never works, but a second or third press a moment later sometimes does, with the clipboard contents untouched. Same pattern #59161 was opened for. Combined with the cold-spawn latency in test #4 (155–171 ms), that's more consistent with a spawn-vs-keystroke race than with a content-detection bug. Happy to instrument the press-side specifically (log each Alt+V, spawn timestamps, exit codes, and whether Claude accepted it; vary the inter-press delay) if it would help a maintainer narrow the window.

Still exists on Claude Code v2.1.159 on Windows 11 in Command Prompt. Used to work fine on older versions. (last month)

For anyone still hitting this on native Windows: even though raw clipboard bitmaps do not paste, Claude Code reliably attaches any image file path pasted as text (.png/.jpg/.gif/.webp). So the workaround is: save the clipboard image to a file and paste its path.

I automated exactly that in a small MIT-licensed PowerShell tool: clipwarp.

clipwarp watch runs a background clipboard listener - take any screenshot (Win+Shift+S, PrtScn, Lightshot, ShareX, browser "Copy image"...), it saves a PNG locally and rewrites the clipboard as dual format: the path as text (for Claude Code) plus the original image (so pasting into Photoshop/Word/Discord still works). Then plain Ctrl+V in Claude Code attaches the image.

It handles the formats apps actually use (CF_BITMAP/CF_DIB, PNG streams, CF_DIBV5 with BITFIELDS, CF_HDROP, HTML data: URIs). No admin rights, no dependencies, 100% local.

irm https://raw.githubusercontent.com/botnick/clipwarp/main/install.ps1 | iex

Hope it helps until this is fixed upstream.

The config in the report shows the likely cause. Windows Terminal binds ctrl+v to Terminal.PasteFromClipboard, so the terminal consumes the shortcut as a text paste and Claude Code never sees the image. If a terminal update reset keybindings to defaults, that would also explain why it worked a month ago. Two fixes: use alt+v, which nothing intercepts, or remove the ctrl+v binding in Windows Terminal settings so the key reaches the app.

Confirming this still reproduces on 2.1.220 (the newest confirmation in this thread was 2.1.159 back in June), and I can corroborate the Windows Terminal diagnosis from the 2026-07-29 comment against a second machine.

Environment

• Claude Code 2.1.220
• Windows 11, PowerShell, Windows Terminal (WT_SESSION present)

The keybinding diagnosis checks out. This machine's Windows Terminal settings.json has an explicit user binding:

{ "id": "User.paste", "keys": "ctrl+v" }

So the terminal consumes Ctrl+V as Terminal.PasteFromClipboard and the key never reaches Claude Code. That matches the earlier hypothesis exactly, and it also explains the "it used to work" reports — a user or a Terminal update adding this binding is enough to break it, with no change on the Claude Code side.

One detail I have not seen described here: the failure can be silent rather than a no-op.

In one case the paste did insert an [Image #N] chip into the prompt — so from the user's side it looked like it had worked — but no image data reached the model, which replied that it had received only the text. A later paste in the same session that carried a real file path (screenshot saved to disk, path pasted as text) did arrive and was read correctly.

So on this setup there appear to be two distinct outcomes:

| What was on the clipboard | Chip inserted? | Image reached the model? |
|---|---|---|
| Raw bitmap (Win+Shift+S, not saved) | yes | no |
| File path as text (saved screenshot) | yes | yes |

The silent variant is the worse one for users: the chip is positive feedback that the attachment succeeded, so when the model says it cannot see the image people assume the model is at fault rather than the paste.

Docs note. The interactive-mode reference already documents the workaround — Alt+V for Windows and WSL, with "use Alt+V if your terminal intercepts Ctrl+V". That line is accurate and it solved it here. It is just not discoverable from the failure: nothing in the CLI surfaces it when a Ctrl+V paste is swallowed. A one-line hint when an image paste yields a chip with no attached data would close most of the reports in this thread.

@Oximito , those two rows might be the same mechanism rather than two. If Windows Terminal is consuming ctrl+v as a text paste, a file path survives because it has a text form and a raw bitmap doesn't, so the second row works for exactly the reason the first one fails.

That would make the chip the actual bug. It appears before anything checks that image bytes arrived, so it reports success on an empty payload. Quick test: does a chip show up on a completely empty clipboard? If it does, it isn't gated on content at all, and the one-line hint you suggested becomes easy to place.

Alt+v bypassing the terminal is consistent with both rows.