claude-code - 💡(How to fix) Fix [FEATURE] Expose attached file paths/bytes to assistant tools so user-attached images can be uploaded without %TEMP% guessing [1 comments, 2 participants]

Problem

When a user attaches an image (or other file) via Claude Code's UI ("ファイルを追加 / Attach file"), the assistant can perceive the image visually (multimodal vision), but has no programmatic access to the file's bytes or its original path on the user's filesystem.

This breaks any workflow where the assistant needs to forward the file to another system (upload to a remote server via scp, copy to a project directory, decode and process the bytes, hand to a CLI like wp media import). The assistant can describe the image perfectly but cannot pass it through.

Current workaround (unreliable)

The only path I found is to GUESS where the attached file might be on disk:

• Search %TEMP% for recently-modified .tmp files
• Heuristically match by mtime / file type / dimensions

This fails frequently because:

• %TEMP% is a shared dumping ground. Edge, Chrome, OneDrive, Discord, screenshot tools, OS update caches, image generators (e.g. Gemini desktop app) all write .tmp files there at similar timestamps.
• Filenames are random UUIDs (4cc3b574-ce8f-4562-b751-ec2235791a77.tmp), indistinguishable from other apps' caches.
• Claude Code's IndexedDB blob store (%APPDATA%\Claude\IndexedDB\https_claude.ai_0.indexeddb.blob\1\<n>\<m>) does contain the attached image (correct size match), but it's wrapped in some Chromium-internal encoding — no \x89PNG signature is present, so a naive byte search fails. Without an official decoder this isn't usable from a tool call.
• Claude Code session JSON (%APPDATA%\Claude\claude-code-sessions\...\local_*.json) does NOT contain the attached image base64 (verified empirically — files are small, no embedded large blobs).

So in practice, the assistant ends up uploading wrong files (a screensaver photo from another app's cache, a 128px favicon, or a webpage screenshot from Edge), then the user has to point out it's wrong, and the cycle repeats.

Repro

1. User attaches a PNG via the UI's "ファイルを追加 / Attach file" button.
2. User: "このアイキャッチをサーバーにアップロードして / Upload this thumbnail to my server."
3. Assistant has the image in its multimodal context (can describe contents perfectly) but no way to scp the actual bytes — there is no file path it can point at.
4. Assistant searches %TEMP%, picks a wrong file, uploads it.
5. User: "違う画像が貼られている / Wrong image is up."

Expected behavior

Any one of these would close the gap:

(a) New assistant tool — read_attachment(message_index, attachment_index, output_path) Writes the bytes of the Nth attachment from the message at that index to a path the assistant chose. Most flexible.

(b) Auto-save attachments to a known, stable directory e.g. ~/.claude/attachments/<session-id>/<message-index>-<attachment-index>.<ext>. Assistant can read with the existing Read tool by following a documented convention.

(c) Expose original source path via system message When the attachment was added via file picker (not paste), include something like:

<attachment index=1 path="C:\Users\foo\Desktop\thumb.png" mime="image/png" />

Less private (path may leak details) but easiest to implement and most useful.

Why this matters

What should be a 1-step task — "upload the attached image to my WordPress site" — becomes a multi-turn debug session of find %TEMP% -mmin -10 ..., visual matching of candidates, repeated wrong uploads, and user frustration:

「ファイル、または写真を追加 から PNG ファイルをわたしているのに受け取れないとはどういう意味だ？」

That's a fair question, and the current architecture doesn't have a satisfying answer for it. The user's mental model — "I attached a file, the assistant has it" — is reasonable. The implementation reality (visual encoder consumes the bytes; no tool exposes them; assistant has to play hide-and-seek with the user's filesystem) is an un-userfriendly leak of internals.

Environment

• OS: Windows 11
• Claude Code (desktop app)
• Use case: filing assistant uploads user-attached images to remote WordPress / VPS via SSH and wp media import

Related (but not duplicates)

• #53980 — Render MCP-tool-returned images inline (about tool OUTPUT, not user INPUT — opposite direction)
• #45477 — Image input docs missing compression details (docs only)
• #43056 — Accumulated inline base64 causes 20MB request limit (about size, not access)