[BUG] Clipboard image paste fails for Chromium/Electron apps (Figma, Chrome) on macOS

Resolved 💬 5 comments Opened Mar 5, 2026 by elomid Closed Apr 3, 2026

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?

Pasting images copied from Chromium-based apps (Figma, Chrome, etc.) into Claude Code via Ctrl+V fails with "No image found in clipboard", even though the image data is present on the clipboard and pasteable into other apps (Obsidian, Notion, Preview, etc.). Dragging image files into the terminal works fine.

What Should Happen?

Claude Code should detect and paste the image from the clipboard, since the PNG data is present as public.png.

Error Messages/Logs

No image found in clipboard. Use Ctrl+V to paste images.

Steps to Reproduce

  1. Open Figma (or any Chromium-based app)
  2. Right-click a frame/element → "Copy as PNG" (or copy any image in Chrome)
  3. Switch to Claude Code in the terminal
  4. Press Ctrl+V to paste the image
  5. See "No image found in clipboard" toast message

You can verify the image IS on the clipboard by pasting into any other app, or by running Finder → Edit → Show Clipboard.

Root Cause

Claude Code's macOS clipboard image check uses:

osascript -e 'the clipboard as «class PNGf»'

This checks for the legacy AppleScript pasteboard type com.apple.pboard.type.PNGf. Chromium-based apps place image data as public.png (the modern UTI type), not the legacy PNGf class. These are different pasteboard types despite both being PNG data.

Diagnostic output after copying from Figma:

All types on clipboard (8 total):
  [477437 bytes] org.w3.web-custom-format.type-0
  [573675 bytes] public.png
  [573675 bytes] Apple PNG pasteboard type
  [47 bytes] org.w3.web-custom-format.map
  [24 bytes] org.chromium.internal.source-rfh-token
  [120 bytes] org.chromium.source-url
  [6598476 bytes] public.tiff
  [6598476 bytes] NeXT TIFF v4.0 pasteboard type

Image type presence check:
  ✅ public.png: 573675 bytes
  ✅ public.tiff: 6598476 bytes
  ❌ com.apple.pboard.type.PNGf (PNGf): not present

NSImage can read clipboard: YES (746x2210)

Claude Code check ('the clipboard as «class PNGf»'): FAILS (exit 1)

Native macOS apps (Preview, Safari) include the legacy PNGf type alongside public.png, which is why pasting from those apps works.

Suggested Fix

Use NSPasteboard directly (via a Swift helper or swift -e) instead of AppleScript's «class PNGf». NSImage(pasteboard:) handles all image types including public.png. Alternatively, add a fallback that checks public.png when «class PNGf» fails.

Workaround

Re-encode the clipboard after copying from Figma to add the legacy type:

import AppKit
let pb = NSPasteboard.general
guard let image = NSImage(pasteboard: pb),
      let tiffData = image.tiffRepresentation,
      let bitmapRep = NSBitmapImageRep(data: tiffData),
      let pngData = bitmapRep.representation(using: .png, properties: [:]) else { exit(1) }
pb.clearContents()
pb.setData(pngData, forType: NSPasteboard.PasteboardType("public.png"))
pb.setData(pngData, forType: NSPasteboard.PasteboardType("com.apple.pboard.type.PNGf"))
pb.setData(pngData, forType: .tiff)

Save as fix_clipboard.swift and run swift fix_clipboard.swift before pasting.

Is this a regression?

I don't know

Claude Code Version

2.1.69 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This bug affects all Chromium/Electron-based apps that copy images to the clipboard — not just Figma. This includes Chrome's "Copy image", VS Code screenshots, Slack (desktop), Discord, etc.

The investigation and this issue were co-authored with Claude Code.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗