[BUG] Images pasted while a background fork (/btw → f) is running are dropped — fork gets a bare `[Image #N]` placeholder with no image block

Status Open
Reported on v2.1.221
Maintainer reply None cached
Activity 0 comments · opened Aug 4, 2026

Summary

Images pasted while a background fork is running never reach the fork. The fork receives the mid-turn wrapper message with a bare [Image #N] placeholder and no image content block, so it reports it cannot see the image and asks for it again. The image is written to disk in the image cache — only the API attachment is lost.

Environment

  • Claude Code 2.1.221 (CLI, TUI)
  • macOS (Darwin 25.5.0), arm64

Steps to reproduce

  1. In an interactive session, run /btw and press f to fork the conversation into a background worker after the response.
  2. While the fork is working, paste an image into the input.
  3. The fork receives the message.

Expected

The fork receives the image as an image content block, the same as any pasted image in a normal turn.

Actual

The fork receives only the placeholder text. The message it gets is:

The user sent a new message while you were working:
[Image #1]

This is how Claude Code surfaces messages the user sends mid-turn — within the running turn, often alongside the next tool result, rather than as a separate conversation turn. Address the message above as you continue this turn.

The fork replies that it cannot read it:

I'm still not able to see the contents of either image — they're arriving on my end as attachment placeholders ([Image #1], [Image #2]) with no rendered content, so I have nothing to read rather than something ambiguous to interpret.

Two images were pasted, ~2 minutes apart; both were dropped the same way.

Evidence from the transcripts

The images were cached to disk correctly, under the parent session's cache directory:

~/.claude/image-cache/<parent-session-id>/1.png   PNG image data, 2000 x 927, 8-bit/color RGBA
~/.claude/image-cache/<parent-session-id>/2.png   PNG image data, 2000 x 927, 8-bit/color RGBA

But scanning every user message in both .jsonl files for content[].type == "image" returns zero image blocks:

  • parent session ~/.claude/projects/<project>/<parent-session-id>.jsonl — no image blocks
  • fork transcript ~/.claude/projects/<project>/<parent-session-id>/subagents/agent-<id>.jsonl — no image blocks; the two mid-turn messages carry only the [Image #1] / [Image #2] text

So the paste handler wrote the file and allocated the placeholder index, but the mid-turn delivery path to the fork dropped the attachment.

Workaround

Referencing the file by path instead of pasting works — the fork reads it via the Read tool and gets the image:

@~/Downloads/qnap.jpg

which produced, in the fork transcript:

[Image: original 2262x1048, displayed at 2000x927. Multiply coordinates by 1.13 to map to original image.]

Related issues (different bugs)

  • #65189 and #70695 — docs gaps around image paste in the agent-view peek/reply surface
  • #71643 — pasted images visible to the model but not written to disk (the inverse of this)
  • #72396 — images sent as file paths instead of inline (v2.1.195)

View original on GitHub ↗