[BUG] Desktop file pane: right-click on a text selection offers no Copy — the context menu is entirely file-scoped
What happened
In the desktop app's Code tab, I opened a file in the file pane, drag-selected a block of
lines, then right-clicked inside the selection. The context menu that appears is entirely
file-scoped:
- Attach as context
- Copy file contents
- Copy path
- Open in → Cursor / VS Code / Windsurf
- Show in Explorer
There is no Copy / Copy selection item. The highlighted text cannot be copied from the
context menu at all — the only copy action, Copy file contents, ignores the selection and
copies the whole file.
The menu does not change when a selection exists, so from the user's side right-click on
selected text is a dead end.
Expected
When a non-empty selection exists in the file pane, the context menu should include a
selection-scoped Copy (plain text) item, ideally as the first entry — the standard behavior
for any read-only text view. The existing file-scoped items can stay below it.
Repro steps
- Desktop app → Code tab.
- Open any file in the file pane (mine was a plain-text
.txt; ~25 lines of a table). - Drag-select a block of lines.
- Right-click inside the selection.
- The menu lists only the file-scoped items above. No way to copy the selected text.
Screenshot
Menu items transcribed above from a screenshot of the file pane with lines 52–76 selected;
the context menu overlaps the right edge of the selection and showsAttach as context / Copy file contents / Copy path / ─── / Open in (dimmed) / Cursor / VS Code /.
Windsurf / ─── / Show in Explorer
Related, but not duplicates
- #85158 — asks for a selection-scoped attach in this same file-pane menu. That request
notes in passing that the menu is file-scoped by design; this report is that the same design
leaves plain copy with no selection-scoped path either.
- #76747, #74239 — the chat transcript's selection menu lacking "Copy selection". Different
surface: there the menu is at least selection-triggered; the file pane offers no
selection-scoped action whatsoever.
Environment
- Claude Desktop 1.25927.0 (verified from the running
claude.exefile version) - Windows 11 Pro 10.0.26200
- Claude Code CLI 2.1.232
Not tested as part of this report: whether <kbd>Ctrl</kbd>+<kbd>C</kbd> copies the file-pane
selection. Even if it does, the context menu should still expose it.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Follow-up on the open question at the end of the report: I tested it, and
<kbd>Ctrl</kbd>+<kbd>C</kbd> does copy the file-pane selection correctly.
So this is narrower than "no way to copy" — the capability exists, it's just not reachable from
the context menu. The bug is discoverability: right-clicking a selection is the first thing most
people try, and the menu that appears gives no indication that copying the selection is possible,
while offering a Copy file contents item that looks like it should do it and doesn't.
That should make this cheap to fix — the selection-copy path already works, it just needs a menu
entry wired to it when the selection is non-empty.
Still open and still relevant. The selection is visible on screen but unreachable from the context menu: every item in it is file-scoped, and the one copy action,
Copy file contents, ignores the selection and takes the whole file.The ask is a single
Copy selectionitem when the right-click lands inside an active selection. Everything else in the menu can stay as it is.Still open. The narrow fact in this report is that the context menu does not change when a selection exists. In the Code tab's file pane, right-clicking inside a drag-selected block produces the same entirely file-scoped menu: Attach as context, Copy file contents, Copy path, Open in, Show in Explorer.
So there is no route from a selection to the clipboard through the context menu. The one copy action present, Copy file contents, ignores the selection and copies the whole file, which is the opposite of what a user who just selected 25 lines wants.
The ask is small: when a non-empty selection exists, add a selection-scoped Copy as the first entry and leave the file-scoped items below it. That is the standard behaviour for any read-only text view, which is why right-click currently reads as a dead end rather than as a deliberate omission.