[BUG] Image paste via X11 CLIPBOARD creates chip but API returns 400 'Could not process image' on Linux/Xvfb (Claude Code 2.1.114)

Environment

| Component | Version |
|-----------|---------|
| Claude Code | 2.1.114 |
| Platform | Linux (Ubuntu/Debian, VPS) |
| Display | Xvfb X.Org 21.1.11, DISPLAY :91, screen 640x480x24 |
| Clipboard tool | xclip 0.13 |
| Terminal multiplexer | tmux 3.4 |
| Claude process env | DISPLAY=:91 + XAUTHORITY confirmed in /proc/<pid>/environ |

Bug Description

When pasting images into Claude Code via the X11 CLIPBOARD selection on Linux (Xvfb), the [Image #N] chip correctly appears in the TUI prompt — confirming the clipboard-to-Claude transport is working — but every subsequent API call is rejected with:

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

This error is identical across all tested image sizes and formats, suggesting the failure is in Claude Code's encoding/payload assembly step rather than in the images themselves or in our clipboard transport.

Steps to Reproduce

1. Start Xvfb display: Xvfb :91 -screen 0 640x480x24 -nolisten tcp -auth /tmp/poc91.Xauthority &
2. Start Claude Code with DISPLAY=:91 XAUTHORITY=/tmp/poc91.Xauthority claude (or attach to a tmux pane already running Claude Code under that DISPLAY)
3. Inject a PNG image into the X11 CLIPBOARD: xclip -selection clipboard -t image/png -i /path/to/image.png
4. Send a tmux keystroke to the Claude Code pane simulating Ctrl+V
5. Observe: [Image #N] chip appears in the TUI — clipboard read confirmed ✅
6. Type any prompt referencing the image and press Enter
7. Observe: API Error: 400 "Could not process image" — vision response never received ❌

Test Matrix (Empirical Results)

We ran four variants to rule out size/format-specific causes:

| Test | Format | Size (bytes) | Clipboard integrity | Chip appeared | API response |
|------|--------|-------------|--------------------:|---------------|-------------|
| 1x1 solid PNG | PNG | 70 | n/a | ✅ [Image #2] | ❌ 400 Could not process image |
| 64×64 skyblue PNG | PNG | 238 | ✅ md5 verified | ✅ [Image #3] | ❌ 400 Could not process image |
| 128×128 JPEG | JPEG | 365 | n/a | ✅ [Image #4] | ❌ 400 Could not process image |
| 1920×1080 blue PNG | PNG | 31,348 | ✅ md5 verified | ✅ [Image #5] | ❌ 400 Could not process image |

Request IDs captured (may be useful for server-side diagnosis):

• req_011CaAv1D5ztEYsvi… (1×1 PNG, 70 B)
• req_011CaAv5fCVkSLzYs… (64×64 PNG, 238 B)
• req_011CaAv8hfuYVpmQB… (128×128 JPEG, 365 B)
• req_011CaAvEGkdMuPqts… (1920×1080 PNG, 31 KB)

Expected Behavior

After [Image #N] chip appears, Claude should describe or process the image contents. The chip is the documented signal that Claude Code has accepted the image for submission.

Actual Behavior

100% of API requests return invalid_request_error: Could not process image, regardless of image format or size. The error message is consistent with the API receiving something it identifies as image-shaped but cannot decode.

Diagnosis / Hypothesis

Based on our testing, the failure appears to be after X11 clipboard transport and before or during API payload assembly. Possible locations we cannot inspect from outside:

1. Claude Code's X11 clipboard read — may request an X selection target our xclip doesn't serve, or mishandle INCR transfers, producing truncated/misencoded bytes prior to base64 encoding
2. Claude Code's base64 encoder — may have a Linux-specific code path with an encoding bug (this path appears to work correctly on macOS based on community reports)
3. Claude Code's API payload builder — may set incorrect media_type, send metadata without pixel bytes, or produce a malformed image content block specifically on Linux

We explicitly tested and ruled out:

• Our source images being invalid (created with sharp; valid on all tested viewers)
• Clipboard transport corruption (md5 of clipboard output matched source file on inject and on verify)
• Size restrictions (70 B through 31 KB all fail identically)
• Format restrictions (PNG and JPEG both fail identically)

Comparison: macOS vs Linux

Based on community reports and documentation, Cmd+V / Ctrl+V image paste works correctly on macOS (chip appears and vision API responds). This suggests the Linux clipboard path in Claude Code has a platform-specific encoding issue not present in the macOS path.

Related Issues

• #834 (CLOSED): "Unable to paste images into Claude Code TUI interface on Linux" — earlier report of Ctrl+V producing no chip at all. Our reproduction is a different failure mode: transport succeeds (chip appears) but API rejects the resulting payload.
• #37062 (OPEN): "Subagent crashes when API returns 400 on image processing" — shares the Could not process image error but via the Read tool, not clipboard paste.

Impact

For teams running Claude Code in headless Linux environments (Xvfb, VPS, CI), image paste is currently non-functional even when the X11 clipboard transport is correctly set up. The chip appearing in the TUI creates a misleading signal that the image was accepted.

We would appreciate any pointers on whether this is a known limitation of the Linux build, a configuration requirement we may be missing, or a confirmed bug. The request IDs above are available if server-side payload inspection would help narrow down the encoding issue.

---

Reproduced by Chertam + TingTing (Pixxie Family team) — 2026-04-18. Evidence from systematic POC with 4 image variants and byte-level integrity verification.