claude-code - 💡(How to fix) Fix Base64 data URI in tool output triggers 'Could not process image' API error, poisons conversation [1 participants]

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#55492Fetched 2026-05-03 04:51:57
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×4

Error Message

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Could not process image"}}

Root Cause

The error is unrecoverable — retrying produces the same error because the poisoned tool output remains in conversation history. The conversation is effectively dead.

Fix Action

Workaround

Write the data URI to a file and use Read to access it in chunks, or avoid letting the full data URI appear in Bash output (e.g., redirect to file without head/preview).

Code Example

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Could not process image"}}

---

echo -n "data:image/svg+xml;base64,$(base64 -i /tmp/pattern.svg | tr -d '\n')" > /tmp/datauri.txt
RAW_BUFFERClick to expand / collapse

Bug Description

When Claude Code generates a base64-encoded SVG data URI (e.g., for inlining into CSS) and the resulting data:image/svg+xml;base64,... string appears in tool output (Bash), the API attempts to process it as an image rather than treating it as plain text. This results in:

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Could not process image"}}

The error is unrecoverable — retrying produces the same error because the poisoned tool output remains in conversation history. The conversation is effectively dead.

Reproduction Steps

  1. Create an SVG file (e.g., a wallpaper group pattern tile, ~5.5KB)
  2. Base64-encode it and construct a data URI:
    echo -n "data:image/svg+xml;base64,$(base64 -i /tmp/pattern.svg | tr -d '\n')" > /tmp/datauri.txt
  3. The data URI (~7.4KB) appears in the Bash tool result
  4. On the next model turn, the API tries to interpret the data:image/... string as an image attachment
  5. Image processing fails → 400 error
  6. Every subsequent message replays the same tool result → permanent failure

Expected Behavior

Base64 data URIs in tool output should be treated as opaque text, not parsed as inline images. The model should be able to read the string and embed it in CSS or other files without the API layer intercepting it.

Environment

  • Claude Code mobile app (remote control session)
  • Model: Claude (conversation from 2026-05-01)
  • SVG file: ~5.5KB, data URI: ~7.4KB

Workaround

Write the data URI to a file and use Read to access it in chunks, or avoid letting the full data URI appear in Bash output (e.g., redirect to file without head/preview).

extent analysis

TL;DR

Write the base64-encoded SVG data URI to a file and use a method like Read to access it in chunks, avoiding direct output in Bash.

Guidance

  • Identify instances where base64-encoded data URIs are being directly output in Bash and redirect them to files instead.
  • Use Read or a similar method to access the contents of these files in chunks, preventing the API from interpreting them as images.
  • Consider modifying the tool output to exclude previews or headers that might trigger image processing.
  • Review the conversation history to understand how the poisoned output is being replayed and find a way to clear or ignore it.

Example

# Instead of directly outputting the data URI
echo -n "data:image/svg+xml;base64,$(base64 -i /tmp/pattern.svg | tr -d '\n')"

# Write it to a file
echo -n "data:image/svg+xml;base64,$(base64 -i /tmp/pattern.svg | tr -d '\n')" > /tmp/datauri.txt

# And then read it in chunks
read -r line < /tmp/datauri.txt

Notes

This approach assumes that the issue is solely due to the API's interpretation of the base64-encoded data URI as an image. Other factors, such as the size of the data URI or specific characters within it, might also contribute to the problem.

Recommendation

Apply workaround: Writing the data URI to a file and accessing it in chunks is a reliable method to avoid the API interpreting it as an image, given the current constraints.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING