Dragging the macOS screenshot floating thumbnail silently discards the image

Summary

On macOS, dragging the screenshot floating thumbnail (bottom-right, after Cmd+Shift+4) into the Claude Code TUI produces nothing — no [Image #N] attachment, no inserted text, no error. The TUI visibly reflows for a single frame, then discards the drop.

Dragging a saved file from Finder into the same prompt works correctly.

The difference is that the thumbnail drag delivers a path into a short-lived staging directory (/var/folders/.../TemporaryItems/NSIRD_screencaptureui_*/), and that file appears to be gone by the time Claude Code reads it.

This matches the regression documented in #48655 with session logs: v2.1.104 read the dropped file at drop time and embedded it as base64; v2.1.108+ no longer does, and fails with ENOENT on exactly these NSIRD_screencaptureui_* paths.

Repro

1. macOS, any terminal that forwards file drops (verified in Ghostty 1.3.1)
2. Cmd+Shift+4, select a region
3. While the floating thumbnail is still visible bottom-right, drag it into the Claude Code prompt

Expected: [Image #1] attached.
Actual: nothing is inserted; the prompt reflows for one frame and the drop is discarded.

What rules out the obvious explanations

I tested each of these directly, because prior reports were closed on theories that don't hold:

| Test | Result |
|---|---|
| Drag saved file, no spaces (dragtest.png) | ✅ attaches as [Image #1] |
| Drag saved file, spaces (Screenshot 2026-07-24 at 22.04.49.png) | ✅ attaches as [Image #1] |
| Drag the floating thumbnail | ❌ silently discarded |

So spaces, shell-escaping, and terminal drop-forwarding are all fine. Both saved-file drags arrive shell-escaped (Screenshot\ 2026-07-24\ at\ 22.04.49.png) and attach correctly, so Claude Code already unescapes properly. Only the thumbnail case fails.

That the thumbnail drop inserts no text at all — rather than leaving the raw path in the prompt — suggests it is recognised as a path and then dropped when the read fails, rather than never being parsed.

Exact bytes delivered by the thumbnail drag

Captured with a raw-mode pty probe (tty.setraw + os.read) in place of the TUI:

[  1] t= 11.215s    133 bytes  b'/var/folders/p4/k9vl.../TemporaryItems/NSIRD_screencaptureui_Z9ThME/Screenshot\\ 2026-07-24\\ at\\ 22.00.42.png'

chunks       : 1
total bytes  : 133
bracketed    : False
backslashes  : 3
leading slash: True

The path is absolute, well-formed, arrives in a single read(), and is not truncated. Nothing is wrong with what the terminal delivers — identical in form to the saved-file drags that do attach.

Staging directory behaviour

• Thumbnail drags stage into /var/folders/<...>/T/TemporaryItems/NSIRD_screencaptureui_<random>/.
• These directories are transient — none persist after the drag completes.
• Dragging the thumbnail also consumes the capture: the screenshot never lands in the configured screenshot folder, so there is no fallback copy on disk.
• The parent TemporaryItems is drwx------ and owned by the user, so this is a lifetime problem rather than a file-permissions one.

Suggested fix

Read the dropped file's bytes synchronously at drop time, before macOS reclaims the staging directory — i.e. restore the v2.1.104 behaviour described in #48655. Alternatively, copy the staged file to a durable location immediately on drop and resolve from there.

Failing that, surfacing the read error instead of discarding silently would at least make the failure diagnosable.

Related issues

• #48655 — same bug, auto-closed as stale. Contains the strongest evidence: session logs pinpointing the v2.1.104 → v2.1.108 regression, plus an independent iTerm2 report on v2.1.121.
• #53631 — same symptom, closed as not-planned and locked, after the reporter concluded it was Warp-specific. That conclusion appears incorrect — it reproduces on Ghostty here, and on iTerm2 per #48655. The lock prevents correcting it in place.
• #40218 — Ghostty-specific report, closed as duplicate. Its stated cause (Claude Code depending on iTerm2's OSC 1337) is not supported: saved-file drags attach fine in Ghostty.
• #2102 — open, but clipboard image parsing, a different code path.

Environment

• Claude Code 2.1.219
• macOS Darwin 25.5.0
• Ghostty 1.3.1; reproduces identically with and without tmux 3.6b
• Also reported on iTerm2, VS Code, and Warp in the issues above

Workaround

Take the screenshot to a file, then paste its path rather than dragging the thumbnail. A pasted path resolves correctly, including with spaces. Dragging the saved file from Finder also works — it is specifically the floating thumbnail that fails.