Copying an assistant message requires a two-step pointer interaction with no bindable keyboard action (screen reader accessibility)

Summary

Copying an assistant message to the clipboard is possible, but only through a disclosure-then-select pointer interaction. There is no bindable keybinding action for it and no /copy command, so screen reader and keyboard-only users pay a substantially higher cost than mouse users for the same task.

This is a parity problem rather than a missing feature. The capability exists; it is gated behind an interaction pattern that is cheap with a pointer and expensive without one.

Current behavior

With a pointer: activate the message's "show actions" control, then activate "copy". Two clicks, both targets visible at a glance.

With a screen reader or keyboard only: navigate to the message, locate the "show actions" control, activate it, then locate "copy" among the revealed actions — each step requiring exploration to find a target that a sighted user simply sees.

The keyboard alternative is worse. The only keyboard path today is manual selection:

1. ctrl+o to toggle the transcript
2. shift+arrow / shift+home / shift+end to extend a selection across the message
3. ctrl+shift+c (selection:copy) to copy

For a long structured response this is dozens of keystrokes, with no way to confirm the selection boundaries by ear. Selection state is inherently visual; extending it blind is guesswork.

Why this matters

The task — "copy what the assistant just said" — is extremely common: pasting output into an editor, a ticket, an email, another tool. It is one of the highest-frequency interactions in the product.

For a screen reader user it is currently one of the most expensive. That inversion is the accessibility problem.

Suggested fix

Add a bindable keybinding action. The keybinding system already exposes 100+ actions across documented contexts, and ~/.claude/keybindings.json already supports user bindings. A chat:copyLastMessage action (and ideally chat:copyFocusedMessage) would let this be a single keystroke.

There is clear precedent and a natural namespace — selection:copy is already bound to ctrl+shift+c in the Scroll context. Note ctrl+c is unavailable, being hardwired to interrupt.

A shipped default binding would be better than requiring users to discover the keybindings file, but even a bindable action with no default would resolve the barrier.

A /copy slash command would be an acceptable alternative or supplement. It does not currently exist; typing /copy returns "isn't available in this environment."

Secondary: ensure the "show actions" control and each revealed action carry clear accessible labels, so the pointer path is at least navigable when the shortcut is not used.

Environment

• Claude Code desktop app, Windows 11
• Verified against the documented keybindings action list: no copy-message action exists in any context
• ~/.claude/keybindings.json not present (no user customization in play)