A Copy button on code blocks in the terminal, on hover (opt-in)

[irisitymichaelgrundberg]

I often open the Response Viewer just to copy a code block. The blocks I copy most are the ones it draws in a box with a Copy button, because copying the same block from the terminal gets it wrong in three ways. Claude Code draws a code block without its fences, it indents every row by a two-column margin, and it word-wraps long lines with no marker, dropping the space at each break. So a terminal selection of a long shell command or a JSON snippet needs fixing by hand before it works.

Codeman already knows which text is a code block, so I built a shortcut. When you hover a code block in the terminal, the Response Viewer's Copy button appears next to it, and a click copies the block as the transcript has it. It's on the feat/terminal-code-copy branch of my fork, and I'm holding the PR until you've had a look.

What it does

• A setting in App Settings, Terminal & Input, called "Copy Button on Code Blocks", switches it on. It's per device, desktop only ((hover: hover) and (pointer: fine)), and off by default.
• Hovering a code block from the agent's answer shows the same rv-copy-btn the Response Viewer uses, next to the block. A click copies the block's text from the transcript, flashes the same copied mark, and leaves focus in the terminal.
• It works for Claude Code and Codex, on this machine or in a Docker case, and for DeepSeek on this machine. Those are the CLIs whose transcripts last-response already reads. Remote sessions and the other CLIs get no button.

How it finds the blocks

The browser fetches GET /api/sessions/:id/last-response?context=full, the Response Viewer's own source, and extracts the code blocks with marked.lexer. It then matches them against the rows on screen, comparing text with whitespace removed, so the margin and the wrapping don't matter. A block cut off at the top or bottom of the viewport still matches. When two blocks could both explain the same rows, those rows get no button, so it never copies the wrong block.

To check this I built synthetic transcripts from 303 real code-bearing answers and had claude --resume draw them at 100x50. Then I graded a 50-row window at every scroll position. The button was on the right block in 7,358 of 7,416 sightings and never on a wrong one. Every block shown whole got its button. All 58 misses were blocks cut off at an edge, and 46 of them showed fewer than 12 characters. A short sliver gets a button only when it is a whole block line of 8 characters or more, because shorter or partial lines also turn up as prose.

Two small API changes

Both add to last-response without changing what existing callers get:

1. The Claude branch now sends an ETag, built from the transcript's path, size and mtime. A request with a matching If-None-Match gets a 304 before the file is read. The button refetches after output while the pointer moves, at most every three seconds, so this keeps an idle hover from re-reading a large transcript.
2. A response that an external CLI's branch segmented from the pane now carries source: 'pane'. Pane text is screen text, not markdown, so the button offers nothing for it.

Questions

1. Is an opt-in hover button over the terminal OK in principle?
2. Is matching in the browser the right place for it? The matcher is a pure function in constants.js, next to the other pure helpers, with tests against a real Claude render.
3. Are the ETag and source: 'pane' fine on a /api/v1 endpoint, or would you rather the button had an endpoint of its own?
4. The branch is about +2,000 lines across 18 files, half of it tests. Is one PR OK, or should the server change go first on its own?

If it's a yes in some shape, I'll send it as one PR referencing this thread.