[BUG] Ctrl+V image paste fails silently — "No image found in clipboard"

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Ctrl+V image paste fails silently — "No image found in clipboard"

Environment

• Claude Code: 2.1.63
• macOS: 15.7.4 (Sequoia), Build 24G517
• Architecture: arm64 (Apple Silicon)
• Terminal: macOS Terminal.app
• Shell: zsh

Summary

Pressing Ctrl+V to paste a clipboard image always fails with "No image found in clipboard. Use ctrl+v to paste images." — regardless of image size or source. The clipboard demonstrably contains valid PNG data. A second Mac with identical OS version, Claude Code version, and architecture does not have this issue.

Steps to reproduce

1. Take a screenshot with Cmd+Ctrl+Shift+4 (copies to clipboard)
2. Verify clipboard contains image data: osascript -e 'clipboard info' shows «class PNGf»
3. Open Claude Code (claude)
4. Press Ctrl+V

Expected: Image is pasted into the conversation.
Actual: Toast notification: "No image found in clipboard. Use ctrl+v to paste images."

Reproducibility: 100% on the affected machine, 0% on a second Mac with identical OS (15.7.4), Claude Code (2.1.63), and architecture (arm64). The issue persists across Claude Code restarts, terminal restarts, and reboots. Screenshot size does not matter — fails even with a 5KB (78×40px) image.

Root cause analysis

The IWT() function (clipboard image reader) returns null, triggering the error. Through extensive debugging, we determined:

What works

• osascript -e 'clipboard info' shows valid PNGf data — in a regular terminal AND inside Claude Code's bash tool
• The full save pipeline works inside Claude Code's bash tool:

``
osascript -e 'set png_data to (the clipboard as «class PNGf»)' \
-e 'set fp to open for access POSIX file "/tmp/claude_cli_latest_screenshot.png" with write permission' \
-e 'write png_data to fp' -e 'close access fp'
``

• Dragging an image file into Claude Code works
• Node.js exec() with explicit maxBuffer: 200MB successfully runs the osascript commands and retrieves PNG data
• Platform detection returns darwin correctly

What fails

• IWT() returns null on every Ctrl+V attempt
• osascript is never spawned during Ctrl+V (confirmed via PATH wrapper interception — a logging wrapper at /tmp/bin/osascript placed ahead of /usr/bin/osascript on PATH was never called)
• The debug log (claude --debug-file) captures no clipboard-related activity on Ctrl+V — only permission setup entries
• fs_usage monitoring of the Claude Code process during Ctrl+V shows no osascript or child process activity related to clipboard

Likely failure point

The IWT() function (decompiled from the binary) uses H1() (execa) to run:

// Step 1: checkImage
"osascript -e 'the clipboard as «class PNGf»'"
// Step 2: saveImage (only if step 1 succeeds)
"osascript -e 'set png_data to ...' -e 'set fp to ...' -e 'write ...' -e 'close access fp'"

The checkImage command dumps the entire image as hex text to stdout just to verify an image exists. When run via Node.js execSync with default buffer, this produces ENOBUFS:

Error: spawnSync /bin/sh ENOBUFS
    at Object.spawnSync (node:internal/child_process:1103:20)
  errno: -55,
  code: 'ENOBUFS',
  syscall: 'spawnSync /bin/sh',

The stdout buffer contained 1,114,112 bytes of hex data from a single screenshot. The catch { return null } in IWT() silently swallows this error.

However, even with a tiny 5KB screenshot (78×40 pixels), the paste still fails on this machine. This suggests H1 (execa) may have a very small maxBuffer configured, or there is an additional failure mode we could not identify due to the silent error handling.

Why the other Mac works

Unknown. Both machines are identical in OS version, Claude Code version, and architecture. The difference may be in:

• A prior clipboard state or cached temp file condition
• An execa configuration difference based on machine-specific state
• A race condition or timing-sensitive issue in the TUI render loop

Proposed fixes

Fix 1: Change checkImage to not dump image data

Replace:

checkImage: "osascript -e 'the clipboard as «class PNGf»'"

With:

checkImage: "osascript -e 'clipboard info' | grep PNGf"

This checks for PNG presence without dumping the multi-megabyte hex representation to stdout. The existing saveImage step already writes to a temp file.

Fix 2: Surface errors instead of silently returning null

Change:

} catch { return null; }

To at minimum log the error:

} catch (e) { debug('IWT clipboard error:', e); return null; }

The current silent catch makes this class of bug nearly impossible to diagnose.

Fix 3: Add maxBuffer to execa calls

If H1 is execa, ensure the checkImage call has a sufficient maxBuffer, e.g.:

await H1(T.checkImage, { shell: true, reject: false, maxBuffer: 50 * 1024 * 1024 })

Diagnostic commands for triage

To verify the clipboard works at the OS and Node.js level:

# OS-level clipboard check
osascript -e 'clipboard info'

# Node.js clipboard check (inside Claude Code bash tool)
node /tmp/test_clipboard.js
# Where test_clipboard.js contains:
# const { exec } = require('child_process');
# const checkCmd = "osascript -e 'the clipboard as «class PNGf»'";
# exec(checkCmd, {maxBuffer: 200*1024*1024}, (err, stdout) => {
#   console.log('exit:', err?.code || 0, 'stdout bytes:', stdout?.length);
# });

What Should Happen?

screen shot should be captured by ctrl + v

Error Messages/Logs

"no image found" error on Claude Code

Steps to Reproduce

Take a screenshot with Cmd+Ctrl+Shift+4 (copies to clipboard)
Verify clipboard contains image data: osascript -e 'clipboard info' shows «class PNGf»
Open Claude Code (claude)
Press Ctrl+V

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.63

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_