[BUG] macOS: images from existing files (paste/drag/path) attach as [Image #X] but Claude only receives a generic "PNG document" placeholder — only fresh clipboard screenshots work

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?

On macOS, any image that already exists as a file on disk is attached to the prompt but never actually reaches Claude.

The CLI displays the attachment normally ([Image #1], [Image #2], ...), but when Claude reads them, every attachment resolves to the same byte-identical ~70 KB PNG (identical MD5) — the generic macOS "PNG document" placeholder icon, not the real image. Claude therefore reports it cannot see the content and asks for a re-attach.

This happens regardless of how the image is provided:

• Copy the file in Finder, then paste with Cmd+V, Control+V or Option+V
• Drag & drop the file into the terminal
• Paste the absolute file path (the path is silently converted into [Image #X], which is then also unreadable)

What DOES work:

• Giving Claude a path to a folder containing images — it reads them without any problem
• Images Claude creates or saves itself (temp files, its own screenshots)
• A freshly taken screenshot (Cmd+Shift+3 / Cmd+Shift+4) pasted directly from the clipboard, or selected via Cmd+Space+4

So the only reliable way to show Claude an existing or edited image is to re-screenshot it with Cmd+Shift+4 first, which is very painful with multiple images.

Additional notes:

• Reproduces in every terminal I tried: Warp, Terminal.app, Termius
• Persists across reinstalls and full reconfiguration
• Terminal has all relevant macOS permissions granted (Full Disk Access, Files and Folders, Screen Recording)
• Ongoing for many months across many versions
• Rarely also observed when uploading images through the Claude iOS app after /rc

<img width="1029" height="212" alt="Image" src="https://github.com/user-attachments/assets/e40833c7-7345-4f44-9f95-99f3b46302de" />

What Should Happen?

Images attached from existing files (clipboard paste, drag & drop, or file path) should be read from the actual file on disk and passed to the model as real image content — identical to the behavior of a freshly taken screenshot pasted from the clipboard. Pasting a file path should either attach the real file or be left as plain text, not be replaced by an unreadable [Image #X].

Error Messages/Logs

Steps to Reproduce

1. On macOS, have any existing image file on disk, e.g. ~/Desktop/example.png (a normal PNG/JPEG, not a screenshot currently in the clipboard).
2. Start Claude Code in any terminal (reproduced in Warp, Terminal.app and Termius).
3. Attach the image in any of these ways:

a. Select the file in Finder, press Cmd+C, then paste into the prompt with Cmd+V (also reproduces with Control+V / Option+V)
b. Drag & drop the file from Finder into the terminal
c. Paste the absolute path, e.g. /Users/<me>/Desktop/example.png

1. The prompt shows [Image #1] as if the attachment succeeded.
2. Ask: "Describe exactly what is in this image."
3. Result: Claude reports it received a generic macOS "PNG document" placeholder icon and cannot see the image. Repeat with 5 images and all attachments are byte-identical (same MD5, ~70 KB each).

Counter-example that works correctly:

1. Take a new screenshot with Cmd+Shift+4 and paste it straight from the clipboard with Cmd+V → Claude sees the image perfectly.
2. Or pass a folder path containing example.png → Claude reads the image fine.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.222

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Warp

Additional Information

• macOS version: 27 Public Beta 2 (issue was present on all macOS 26.x versions as well / for months), Mac model/chip: M3 MacBook Air
• Reproduced in Warp, Terminal.app and Termius — so it looks independent of the terminal emulator.
• Survives reinstalling Claude Code and wiping/recreating the configuration.
• All macOS permissions granted to the terminal (Full Disk Access, Files and Folders, Screen Recording).
• Hypothesis: when the clipboard/drag payload is a file reference rather than raw image data, the CLI appears to read the Finder icon/thumbnail representation of the item instead of reading the bytes at the file path. That would explain why all attachments end up as the same 70 KB generic "PNG document" icon, why raw clipboard bitmaps (screenshots) work, and why folder paths read from disk work.
• Suggested fix direction: when the pasted/dropped item is a file URL, resolve the path and read the file from disk; when a plain path is typed, don't convert it into an image attachment placeholder.

<img width="1029" height="212" alt="Image" src="https://github.com/user-attachments/assets/904637b7-6b75-4800-a815-d3694b959e47" />

<img width="1024" height="1024" alt="Image" src="https://github.com/user-attachments/assets/252b3686-53d5-4c33-af50-39840eb3d665" />

MD5 Hash (always identical in all "placeholder" files Claude actually sees in the end for correctly uploaded/pasted images): 8c43397c16890511ec1f2d44f2ff5ce2