[Bug]: Copying text from the Files panel returns only part of the file#15927

Triage

Thanks @saibotma for the clear report, and for checking the file size against the preview limit. That ruled out the obvious suspect right away.

What I found

• A file opened by absolute path (outside the workspace) is shown read-only through SourceFilePreview in apps/web/src/components/files/FilePreviewPanel.tsx, not the editable surface. The full file is loaded: 9,969 bytes is well under the 1 MB read cap, truncated stays false, and file.data.contents holds the whole document.
• That preview renders through the @pierre/diffs virtualizer. Past 50 lines it only mounts a window of lines around the viewport (this panel uses an overscroll of 600px). Line numbers and the spacer rows above and below that window are user-select: none, so a copy only picks up the source lines currently in the DOM. At a typical panel height, a 226-line file mounts roughly the first 100 to 200 lines, which matches the partial paste.
• Cmd+A then Cmd+C selects just that mounted window. During a drag selection, scrolling moves the window in 50-line chunks and the lines that leave it drop out of the selection, so the copy ends up with only what's still mounted.
• Files inside the workspace go through the editable surface, where Cmd+A selects the full text model, so they don't show the Cmd+A case. A drag that scrolls there still follows the mounted window.
• #12943 (and its open fix #12995) is about chat timeline selection, which uses a different list and not this preview.

Likely fix area

SourceFilePreview / FilePreviewPanel.tsx. Options include building the copied text from the loaded string instead of the mounted nodes (so Cmd+A then Cmd+C returns every loaded line), and keeping a drag selection's range across lines that scroll out of the render window. The editable workspace surface might want the same treatment for scrolling drags.

A maintainer will decide on the fix direction.

Another data point, on Windows (T3 Code on Gartlan PC, connected to a remote Linux environment, 2026-10-19):

• File: a ~300-line .jsonc file outside the project workspace, opened from a file link in the chat, so it shows in the read-only preview.
• Drag selection: starting at the first line and dragging to the end while the panel scrolls, the selection ends up covering only roughly the bottom half. The top lines drop out as they scroll away, which matches the virtualizer explanation above.
• Ctrl+A: with the preview focused by clicking in it, Ctrl+A selects the entire app UI (sidebar, chat, everything), not the file. So on Windows there is no keyboard path to the full file either, not even the partial mounted window.

The practical result: copying a whole external file wasn't possible, and I had to ask the agent to paste the contents into chat instead. A copy-contents action would sidestep this; I've suggested it separately in Ideas.

Reproduced on main b5a226e49c in the Linux web dev app, using an external /tmp/issue-15927.sql fixture with 226 SQL lines (11,752 bytes).

Clicked the first source line, pressed Ctrl+A then Ctrl+C, and pasted into the composer without sending: the paste contains only SQL lines 001–100; lines 101–226 are missing. Separately, dragging across lines 1–30 then scrolling to the end clears the selection (1,508 selected characters → 0).

Select/copy/paste recording. The recording starts with the preview at the top: click source, select all, copy, then paste into the composer.

This verifies the web path; macOS Desktop and Windows Desktop were not tested here. No duplicate found among open issues from the last 90 days; the chat timeline and terminal selection reports affect different surfaces.

Draft fix: #23244. On a073960a3d, Linux Chrome checks at 1440 and 390 pixels in both themes copied all 226 SQL statements; a partial selection also survived row eviction. The 23 scoped tests pass. Native Desktop and the full proof matrix remain unverified; the PR records the gaps and remains draft.

Another data point, from the Diff panel as well as the Files panel (T3 Code Desktop on Windows, nightly from around 2026-10-16; exact build unknown).

• Drag-selecting about 300 lines of a roughly 600-line file with the mouse and pressing Ctrl+C copies only the last ~150 lines. It happens every time, in both the Files view and the Diff view of the right-hand panel.
• This matches the virtualization explanation above. @pierre/diffs VirtualizedFile mounts a window of hunks around the viewport, and rows that scroll out during a drag are replaced by buffer spacers, so they drop out of the native selection.
• PR #23248 changes only ReadOnlySourcePreview / useSourceTextSelection. The Diff panel renders through DiffPanel.tsx → AnnotatableCodeView → StyledDiffCodeView (Pierre CodeView), so the diff case looks like it would still be broken after that PR lands.

Posted via t3 triage by Claude Code (Claude Opus 5.5).

Another report from T3 Code Desktop connected to a remote Linux server (server 0.1.2, 2026-10-27).

Opening a file from a path in the chat shows it in the right-hand preview, but the full source cannot be recovered from that panel:

• Long lines are cut off at the right edge. The panel cannot be widened enough, and there is no way to reach the rest of the line.
• Selecting and copying returns only the visible fragment, not the file on disk.
• If that preview is not shown, there is no other action to open the same file and copy it.

The workaround is asking the agent to paste the file into the chat. That matches the Windows remote-environment note above: copying the whole file was not possible.

Also reproducible on T3 Code Desktop 0.1.3-nightly.20261026.3726 (Linux, Wayland).

A 156-line SQL file opened in the side Files panel: Ctrl+A then Ctrl+C then paste gave an incomplete file every time. One paste was missing the last ~55 lines, another was missing the first ~55 lines, depending on where the panel was scrolled. Copying the same file from a normal text editor gave the complete text. This matches the row-eviction explanation above.

Practical impact: we were copying a database script into another tool. It failed to parse, so nothing ran, but a silent partial copy of a long script is a real hazard. Looking forward to #23244.

Additional report on T3 Code Desktop 0.1.6, macOS arm64 (Darwin 27.0.0), on November 2, 2026.

The user opened a SQL file generated by a T3 thread under /private/tmp. Cmd+A followed by Cmd+C in the file viewer copied only the first 100 lines of a 563-line file. Opening the same file in Cursor allowed the full file to be copied.

Read-only triage checks verified that the file on disk contains 563 lines and 40,069 bytes. Desktop Info.plist and the installed application package both report version 0.1.6; the separate triage CLI reports 0.1.2.

The installed 0.1.6 ReadOnlySourcePreview bundle uses Pierre’s Virtualizer with overscrollSize: 600 and intersectionObserverMargin: 1200. This is consistent with the rendered-row selection diagnosis and the earlier lines 1–100 reproduction in this issue. The reported clipboard cutoff was not independently replayed in this triage session. Restricted shell network access prevented cloning the release source, so the installed application bundle and public upstream source were inspected instead.

Workaround: copy the complete file from Cursor. No local application fix was applied. The SQL contents, original filename, and private thread details are omitted.

Prepared by Codex (GPT-6), via t3 triage.