[Feature Request] Allow passing image file paths as strings instead of embedding images

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/12328
2. https://github.com/anthropics/claude-code/issues/9465
3. https://github.com/anthropics/claude-code/issues/13608

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

It is a dupe but the original issue https://github.com/anthropics/claude-code/issues/12328 is locked and it recommends creating a new one.

Please - while I may be one of the few complaining about it - this is probably a silent pain for thousands, if not billions, of Claude-addicts like me. Claude isn't able to extract the path or raw image data from the pasted image, so if you're like "hey can you use this image in the website", it's like, "nope, sorry, gimme the path".

Below is an example of one such annoying interaction - where I finally got the image paths in by copying them into something else - removing the "g" in jpeg" and then re-adding it after pasting.

<img width="960" height="586" alt="Image" src="https://github.com/user-attachments/assets/8903fec6-ff3a-483b-a295-d7317bf5d0d7" />

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Yep it's still happening. Still gives be trouble about 5 times/day on average. Come on this is a 1 line fix, Claude could do it in like 10s.

I'm having trouble too. Sometimes the path is more important than the image itself, so I'd like to see this fixed.

All we need is a setting that makes it possible to disable this.

I need to do like over 30 image paths manually and this is annoying as hell to work with. Can someone from the team launch an agent and get this fixed in 5 mins?

+1. Pasting/copying images into terminal embeds them instead of preserving the file path. Videos already appear as paths — images should have the same option. A setting to toggle this would solve it. Still hitting this daily.

Any update on this? This is one of the features that hasn't been fully thought through. A simple toggle to disable auto-embedding would go a long way.

When I try to paste a path to a larger file (e.g. a 6-7 MB GIF), the auto-embedding completely freezes my Claude Code session and I have to restart it. This makes it genuinely unusable for certain workflows, and I hit this issue on a daily basis.

My current workaround is to paste the path elsewhere, remove a character from the extension, paste it into Claude, and then re-add the missing character, which puts me off all the time.

Would love to see a toggle to prevent this from happening.

Really needed!

Needed!
(+1 vote)

On a mac, command+shift+c copies the path instead of the image. In Claude code, could we use command+shift+v to paste the path instead of the image itself? This is still a very frustrating issue in 2026.

This has become a big workflow issue for me as well. I regularly copy paths from the Finder and expect Cmd-V to paste the paths as text, not image references. If I wanted an image reference I'd either drag the images in or copy the image and paste with Ctrl-V. Now I have to first paste the paths into a TextEdit document, change the path slightly so it doesn't really resolve, paste, and then change the path again so it's correct. That's a lot of wasted time.

Lookling like we might be getting superintelligence before we get the ability to paste image paths into claude code.

This is still happening and it's very annoying. My workaround is to change the path to a relative path before copying it to Claude Code

Agreed this is an extremely annoying issue. I end up pasting the full path elsewhere, deleting the final character, pasting that to Claude, and then manually typing the final character.

Still present in 2.1.252 (Linux, gnome-terminal). Adding some findings that sharpen what the fix should be.

The path is not just "also attached" — it is dropped. Checked the session transcripts (~/.claude/projects/*/*.jsonl): every user message carrying an image block has the text [Image #N] plus whatever I typed; the original path string is not in the message. So when the goal is "put this path into a config file / src attribute", the model never sees the path at all. It has to guess or ask.

Print mode does not have the problem. echo "insert /abs/path/pic.png into header.html" | claude -p keeps the path in the message text (the image is attached in addition). Only the interactive input converts the path to a chip and discards the text.

What triggers the conversion (tested with -p, same detection): absolute or ./-relative path, image extension, file exists. Backticks, quotes, and trailing whitespace do not prevent it. A bare relative path (assets/pic.png) or a non-existent path stays text — which is why the "strip the last char / make it relative" workarounds above work.

Requested behavior: only convert when the clipboard holds actual image data (binary). A clipboard that holds a plain string should be pasted as that string, exactly like every other terminal program does. A file path is text; deciding on the user's behalf that they meant the pixels is a guess, and in the "put this path somewhere" case it destroys the input. If auto-attach from a pasted path is kept for people who like it, it needs to be an opt-out setting and the path text must stay in the message alongside the chip.

This is incredibly annoying functionality.
If I were pasting an image direct from clipboard, then this would be appreciated. But when I'm pasting a path, _I want to see a path_ pasted.