[Bug] Fullscreen TUI: Cmd+C intercepted by internal selection, breaks macOS mouse copy
Bug Description
Claude Code fullscreen TUI: copy is broken on macOS
Environment
- macOS, Claude Code in fullscreen TUI mode (/tui fullscreen)
- Reproduced in two terminals: Apple Terminal and Prompt by Panic
- Clipboard writes from Claude are disabled in my settings
- Prompt has BEL/bell suppression enabled — the beep still occurs there
What happens
1. Mouse-select text in the fullscreen TUI (visual selection appears).
2. Press Cmd+C.
3. macOS system error beep. Nothing reaches the clipboard.
4. Switching to /tui default makes the problem disappear entirely.
Likely cause
In fullscreen, cmd+c is bound to Claude's internal selection:copy action in the Scroll context. That intercepts Cmd+C before the
terminal can run its standard copy. Claude's action operates on its keyboard-driven selection (shift+arrows), not the terminal's
mouse selection — so the action runs with nothing selected and macOS plays the "no valid action" beep.
Secondary issues found while debugging
- The on-screen hint tells Mac users to use Ctrl+C to copy, which is non-standard on macOS and conflicts with app:interrupt.
- cmd+c is listed as a default binding for selection:copy AND in the documented "macOS reserved / non-rebindable" list — these
contradict each other.
- Attempting to unbind cmd+c in the Scroll context via keybindings.json (setting it to null) was rejected by /doctor AND broke
copy entirely, with no workable override available.
- Net result: there is no user-accessible way to make mouse-select + Cmd+C work in fullscreen.
Requests
1. Let Cmd+C fall through to the terminal when Claude has no internal selection (or when the selection originated from a mouse
drag).
2. Or: make Claude's mouse capture optional via a documented setting so terminal-level mouse selection works normally.
3. Show "Cmd+C" instead of "Ctrl+C" in copy hints on macOS.
4. Resolve the contradictory docs around cmd+c being both a default and "non-rebindable."
Workaround
/tui default — fullscreen is unusable for copy-heavy work on Mac until this is fixed.
Environment Info
- Platform: darwin
- Terminal: tmux
- Version: 2.1.167
- Feedback ID: c18bb32a-a045-417a-9b24-666bcad652ae
Errors
[]Showing cached comments. Read the full discussion on GitHub ↗
7 Comments
+1
+1
+1
+1
+1
Additional data point from Ghostty on macOS, which may help narrow this down.
Environment
"tui": "fullscreen","copyOnSelect": falseSymptom
With a mouse selection active in the fullscreen TUI:
| Key | Result |
| --- | --- |
|
Ctrl+C| copies (works) ||
Ctrl+Shift+C| nothing copied ||
Cmd+C| nothing copied |This contradicts the fullscreen docs, which state:
Ctrl+Shift+Cfailing on a mouse selection seems worth calling out separately: it is the documented manual-copy key, it needs no Cmd modifier at all, and it still does not copy. That points at the code path rather than at modifier delivery.Two distinct causes, and evidence separating them
1. Ghostty consumes
Cmd+Cbefore Claude Code sees it.Ghostty binds
super+c=copy_to_clipboard:mixedby default, and none of its default keybinds use theperformable:prefix (verified withghostty +show-config --default). SoCmd+Cis swallowed by the terminal and never reaches Claude Code. Users can opt out with:which makes Ghostty keep
Cmd+Conly when it has its own selection, and forward the key otherwise.2. Even when the key is delivered, copy still does not happen.
After applying the above, I confirmed
Cmd+Cdoes reach the application. With the kitty keyboard protocol enabled manually:Cmd+Cemits^[[99;9u(keycode 99 =c, modifier 9 = super), so the modifier is encoded and delivered correctly by Ghostty.Despite that,
Cmd+Con a mouse selection in Claude Code still copies nothing. This is consistent with the diagnosis in this issue thatselection:copyoperates on the keyboard-driven selection (Shift+arrows) rather than the mouse selection.Why this matters for the docs
Because of cause 1, the documented claim that
Cmd+c"also works" on Ghostty cannot hold with a stock Ghostty configuration, regardless of the underlying bug: the terminal keeps the key. It may be worth either documenting theperformable:opt-in or removing Ghostty from that list until cause 2 is fixed.Workaround that does work today
Hold
Shiftwhile click-dragging to force a native Ghostty selection, thenCmd+Ccopies normally. This keeps fullscreen rendering enabled, unlike switching to/tui default.Thanks for the detailed insights, Ilan. It sounds like there's
definitely a conflict with Ghostty's key bindings that needs
addressing. Your workaround is a solid temporary fix. Have you
considered suggesting a change to the documentation to clarify this
for users?