Alt+V image paste broken on Windows (regression — accessibility impact for eye-gaze-only users)

[mull2536]

Summary

The default chat:imagePaste shortcut (Alt+V) stopped working on Windows
after a recent Claude Code update. Pressing Alt+V with an image on the
clipboard does nothing — no error, no paste, no visible feedback.

Environment

• OS: Windows 11
• Claude Code: latest (auto-updated)
• Terminal: Windows Terminal + PowerShell
• Input method: eye-gaze tracking only

Reproduction

1. Copy an image to the Windows clipboard (Win+Shift+S snip, or right-click
   any image → Copy)
2. Focus the Claude Code chat input
3. Press Alt+V

Expected: image attached to the message.
Actual: nothing happens — no attachment, no error, no visual feedback.

Diagnostics already done

• /doctor reports no keybinding configuration issues.
• ~/.claude/keybindings.json does not exist — defaults are in use.
• Confirmed via reference that Alt+V is the documented default for
  chat:imagePaste in the current Claude Code version.
• Confirmed real image data is on the Windows clipboard (Paint paste works;
  an AutoHotkey hotkey on the same Alt+V successfully reads the clipboard
  image via [System.Windows.Forms.Clipboard]::GetImage()).
• Tested with several plugins installed and after /reload-plugins.
  Behaviour unchanged.
• Drag-and-drop from Windows Explorer works as a workaround.
• Used to work consistently for a long time before a recent Claude Code
  update.

Accessibility impact

I am an ALS patient, locked-in, eye-gaze-only. Keystrokes are my entire
input channel. Drag-and-drop from File Explorer is technically possible
with eye-gaze but slow, fatiguing, and imprecise compared to a keyboard
shortcut. The current workaround I am using is an AutoHotkey script that
intercepts Alt+V, saves the clipboard image to a known file path via
PowerShell, and types the path into the input. That works — which
confirms (a) the OS clipboard does contain image data, and (b) a separate
process can read it via the standard Windows clipboard API. The bug is
in Claude Code's clipboard-read or Alt+V handling on Windows.

Please prioritise — losing a default keyboard shortcut for image input
is an accessibility regression for keyboard-only users, not a minor
inconvenience.

Likely cause

Either a recent Claude Code update changed how the Windows clipboard
is read for image data, or it changed how the Alt modifier is captured
in the terminal input layer on Windows. I have not changed any
configuration on my side.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Claude code CLI cannot paste Image #58923
2. [BUG] Windows Alt+V image paste: first press always fails, second press succeeds (v2.1.141 partial fix of #56792) #59161
3. [BUG] Paste image not working #58518

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[jshaofa-ui]

Alt+V Image Paste — Root Cause Analysis & Proposed Fix

Diagnosis

This is a regression confirmed by extensive user diagnostics. The AutoHotkey workaround proves the Windows clipboard contains valid image data — the bug is in Claude Code's clipboard handling or keybinding layer.

Most Likely Root Cause: Clipboard Format Detection Gap

Windows snipping tool (Win+Shift+S) produces images in CF_DIB / CF_DIBV5 format. If a recent update narrowed the clipboard format check (e.g., only checking CF_BITMAP or image/png MIME type), it would miss the snipping tool's output format.

Investigation Priority Order

1. Clipboard format detection — The handler likely checks for specific formats. Win+Shift+S produces CF_DIBV5, which may not be in the checked list after a recent change.
2. Keybinding resolution — Windows Terminal may intercept Alt+V. Check if keybinding resolution order changed.
3. Node.js/Electron clipboard API — If clipboard.readImage() behavior changed in a dependency update.

Proposed Fix (TypeScript)

// Expand clipboard format detection to cover all Windows image formats
function readClipboardImage(): NativeImage | null {
    // Primary: Electron's built-in (covers CF_BITMAP, CF_DIB)
    let image = clipboard.readImage();
    if (!image.isEmpty()) return image;

    // Fallback: try reading from file list (some apps put image paths via CF_HDROP)
    const files = clipboard.readFilePaths?.() ?? [];
    if (files.length > 0 && isImageFile(files[0])) {
        return nativeImage.createFromPath(files[0]);
    }

    // Windows-specific fallback: use Win32 API via node-ffi
    if (process.platform === 'win32') {
        image = readClipboardImageWin32();
        if (!image.isEmpty()) return image;
    }

    return null;
}

Accessibility Impact

Critical — The user is an ALS patient using eye-gaze-only input. Keyboard shortcuts are their entire input channel. This is not a minor inconvenience; it's a total loss of image input capability.

References

• User's diagnostics: AutoHotkey successfully reads clipboard image via [System.Windows.Forms.Clipboard]::GetImage()
• Windows clipboard formats: CF_BITMAP, CF_DIB, CF_DIBV5, CF_HDROP
• Related: [BUG] Claude code CLI cannot paste Image #58923, [BUG] Windows Alt+V image paste: first press always fails, second press succeeds (v2.1.141 partial fix of #56792) #59161, [BUG] Paste image not working #58518 (possible duplicates)

[mull2536]

Acknowledged as a duplicate of #58923 — happy to let this close in favour of the earlier thread. Two things worth preserving on #58923 before that happens, which I'll cross-post there:

1. Accessibility impact. This is not a minor inconvenience for eye-gaze-only users — Alt+V is the only practical way to attach a screenshot. The AutoHotkey workaround in my issue body works but requires custom keybinding setup that's out of reach for most accessibility users.
2. Root-cause analysis by @jshaofa-ui (above) — points at the clipboard format detection gap: Win+Shift+S produces CF_DIBV5, which a recent change may have filtered out. Proposed TypeScript fix in the same comment.

#59161 looks like the same underlying bug with a different surface symptom (first press fails, second succeeds vs. always fails); jshaofa-ui's diagnosis likely covers both. #58518 is a separate WSL-specific issue.

👎 the auto-close bot to prevent silent closure while we cross-post.