[FEATURE] Expose pasted image data to hooks and plugins
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
When users paste images into Claude Code conversations, there is no programmatic way to access the raw image data (base64 or file reference) from hooks, plugins, or skills. Claude can see and analyze images through vision capabilities, but cannot extract or pass the underlying data to external tools.
This makes it impossible to build plugins that save pasted images to disk, process images with external tools like ImageMagick or Pillow, upload images to external services, or include images in automated workflows.
I attempted to build a plugin that saves pasted images to disk. The skill assumes Claude can "extract base64 data" from images, but this is architecturally impossible with current capabilities.
Related issues: #14150 (MCP tool image results), #9567 (Hook environment variables empty), #592 (Allow Claude to see images)
Proposed Solution
Expose image data through one or more of these mechanisms:
Option A: Hook-based access
Add a new hook event UserPromptSubmit that includes image data:
{
"event": "UserPromptSubmit",
"prompt": "Save these images",
"images": [
{
"index": 0,
"media_type": "image/png",
"base64": "iVBORw0KGgo...",
"temp_path": "/tmp/claude-images/img_001.png"
}
]
}Option B: Temporary file references
Automatically save pasted images to a temp directory and provide paths via environment variables:
$CLAUDE_IMAGE_1=/tmp/claude-code/session-abc/image_001.png
$CLAUDE_IMAGE_2=/tmp/claude-code/session-abc/image_002.pngOption C: Built-in tool for image extraction
Provide a built-in tool that plugins/skills can call:
claude-code --get-image 1 --output /path/to/save.pngAlternative Solutions
Current workarounds all have significant limitations:
Asking users to provide file paths instead of pasting defeats the purpose of the paste feature and degrades UX. Using clipboard-reading Python scripts only works if user just copied the image, and doesn't work for multiple images or images pasted earlier in conversation. Having users manually save images first adds friction and requires user to remember filenames.
Use cases this would enable: saving screenshots to organized folders with meaningful names, processing/compressing images before analysis, integrating with asset pipelines like Obsidian vaults, and extracting text via external OCR tools.
Priority
High - Significant impact on productivity
Feature Category
Developer tools/SDK
Use Case Example
I'm building a plugin to organize YouTube video notes in Obsidian. User pastes 6 screenshots from a tutorial video into the conversation. User says "save these images to my Obsidian vault with timestamps". With this feature, my plugin could access the raw image data via hook or environment variable, save each image to the appropriate Assets folder, and name them based on context (e.g., "Rule_of_Octave_timestamp_1.png"). Currently this is impossible because Claude can see the images but cannot extract their data to save them.
Additional Context
Environment: Windows 11, Claude Code 2.x
The Claude API supports images via base64, URL, or Files API - but Claude Code doesn't expose this data to plugins/hooks after images are pasted into a conversation.
8 Comments
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.
Additional Use Case: Image-Aware Context Management / Compaction
Adding a related but distinct pain point that compounds the need for this feature.
The problem: Screenshots/images consume 86% of conversation context in visual UI iteration workflows. In a recent session doing Electron widget development with Chrome MCP screenshots, a single session accumulated ~7MB of base64 image data across tool results. When auto-compaction triggered, it took 12+ minutes because Claude had to summarize the entire context including all that image data.
Analysis breakdown from a real session transcript (8MB total):
What we need: The ability to mark images as ephemeral/disposable so they can be stripped from context before compaction. Screenshots are transient by nature — once Claude has seen and acted on them, the base64 data serves no purpose. A text description of what was in the image is sufficient for continuity.
Proposed additions to the original feature request:
This would dramatically reduce compaction time and extend useful session length for any workflow involving visual feedback (UI development, design review, browser automation).
cc: relates to #13480 (oversized images breaking conversations)
Yes this is most definitely still an issue for me as well
These are both issues for us as well - any idea when this might be coming?
Same need here. I regularly want to paste screenshots and save them directly to project folders. The image data being vision-only and not writable to disk is a real gap.
+1 on this. I run into this exact limitation daily.
My use case: I paste screenshots into Claude Code (VS Code extension) during conversations — ticket analyses, roadmap items, UI reviews — and want Claude to save them to a project subfolder (e.g.,
screenshots/) so I can reference them later without manually saving first.Currently I have to break my flow, open Preview, paste from clipboard, save to the right folder, then go back to the conversation. This defeats the purpose of having an AI assistant that can "see" my images but can't do anything with them beyond the current conversation.
Option B (temp file references) would already solve 90% of my use case. Even just having
$CLAUDE_IMAGE_PATHavailable would let us build skills/hooks that handle the rest.+1 — this gap becomes especially absurd in the most common workflow it blocks:
I paste a screenshot/mockup and tell Claude "use this image as the hero on the landing page" or "add this diagram to the docs page at section X". Claude can see the image perfectly, knows exactly where in the HTML/JSX it should go, and even writes the correct
<img src="assets/hero.png">tag — but the file atassets/hero.pngnever exists, because Claude can't write the pixels it just saw to disk.So I get working code referencing a file I now have to manually save, name correctly, and place in the right folder. The model did 95% of the work and stopped at the trivial part.
Option B (temp file paths via env vars) would unblock this completely — even without full hook integration, just
$CLAUDE_IMAGE_Npaths would let the existingRead/Write/Bashtools do the rest. The model already knows where the asset belongs in the project; it just needs the bytes addressable.This is the single biggest UX gap between Claude Code and using ChatGPT/Cursor/Claude Desktop for any visual-asset-driven task.
Agree this issue is causing substantial workflow issues - a problem that should not exist and needs resolution.