[Bug] Pasted images lose content in /btw forks, arrive as empty placeholders

Bug Description
Pasted images silently lose their content in /btw forks — the model receives a bare [Image #N] token with no image data.

Version: Claude Code v2.1.223, Opus 5, Linux (GNOME/Wayland), 2026-08-06.

What happened: I asked a question in a /btw fork and pasted a screenshot. The fork said it couldn't see any image. I pasted twice more, same result — every attempt arrived as a bare [Image #1] / [Image #2] placeholder with no image bytes.

Nothing on my side indicated a problem. The terminal accepted the paste and rendered the [Image #N] reference exactly as it does when images work. No error, no warning, no "attachment failed" notice. The only symptom is the assistant saying it can't see the image, which reads as the model being unhelpful rather than as a transport bug.

Cost several round trips: the fork produced two confident-but-wrong answers derived from inference because it couldn't see the screen, and I re-pasted twice assuming I'd done something wrong.

What worked: the same screenshot reached the main session when supplied as a file path — arrived as [Image: source: /path/to/shot.png] with real content, read correctly first try.

Repro: run /btw <question>, paste a screenshot into the fork, observe the placeholder-without-data. Both sessions here were background jobs, so that alone doesn't explain it.

Suggested fix: surface the failure at paste time instead of letting the assistant discover it downstream — and where the image is already a file on disk, pass the path when the attachment can't be inlined.

Environment Info

• Platform: linux
• Terminal: xterm-256color
• Version: 2.1.223
• Feedback ID: dd07a81a-bca2-4015-bf26-6f79bb095d3c

Errors

[]