[BUG] macOS app: a selection dragged across a scroll silently drops content when copied

Summary

In the macOS desktop app, making a text selection that spans more than one viewport — click, then scroll down a long way, then release — produces a selection that looks complete on screen, but copying it (Cmd+C) yields output with a chunk missing from the middle. The longer you scroll while selecting, the more is lost.

The failure is silent: there is no visual cue that the selection is partial. You only find out after pasting somewhere else and noticing the gap, which is especially painful when the whole point was to grab a long stretch of a conversation in one go.

Steps to reproduce

1. Open a session with a long transcript (many screens of scrollback) in the macOS desktop app.
2. Click and hold at some point near the top of the transcript.
3. Drag/scroll down through several screens' worth of content.
4. Release, then Cmd+C.
5. Paste into any editor.

Expected: the full range from anchor to focus.
Actual: the beginning and the end are there, but content in the middle — roughly the part scrolled past between the anchor screen and the release screen — is missing.

Environment

• Claude Code 2.1.252 (macOS desktop app)
• macOS 26.5.2 (arm64)

Note on the reporter's impression

It subjectively reads as "there's a cap on how many lines a selection can copy," but that framing may be misleading — see the hypothesis below. I have not measured a precise threshold, and I don't know whether the amount lost scales with distance scrolled, with time held, or with number of messages crossed. Happy to run a more careful bisect if it would help.

Hypothesis (unverified)

If the transcript is rendered with a virtualized list — only the nodes in (or near) the viewport kept in the DOM — then nodes scrolled past during the drag get unmounted mid-selection. The browser's selection range still spans anchor to focus, but the intermediate nodes no longer exist to serialize, so the clipboard write skips them. That would explain both the silence and why the loss tracks how far you scrolled rather than any fixed line count.

If that is what's happening, possible directions: serialize the copy from the underlying transcript data rather than from the live DOM on copy, or keep selected-but-offscreen nodes mounted for the duration of an active selection.

Workaround for anyone hitting this

The transcript is on disk as JSONL, so the content can be pulled without touching the mouse:

~/.claude/projects/<encoded-project-path>/<session-id>.jsonl

jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="text") | .text' <session>.jsonl | pbcopy