[FEATURE] Raise the ui.copy plugin event for copy on select, so a plugin can rewrite the copied text

Status Open
Reported on v2.1.289
Maintainer reply None cached
Activity 1 comment · opened Oct 5, 2026

What I was trying to do

In the fullscreen TUI, text copied by mouse selection comes with the left gutter bar glyph and with hard line breaks in the middle of sentences, at the column where the row wrapped. That symptom is already tracked in #81472 (root causes 1 and 2), so this issue is not about it.

This one is about the plugin API: I tried to fix the copied text with a plugin (function hooks) and could not do it at the source.

The gap

The ui.copy event is documented as rewritable ("a hook may rewrite, refuse or take it"), but the engine's own copy on select does not raise it. As far as I can tell from the 2.1.289 build, that path writes to the clipboard directly, so a ui.copy hook only ever sees copies made by plugins through $.ui.copy, never the selection copy.

// Never runs when the person selects text with the mouse.
on('ui.copy', ($, e, next) => next({ ...e, text: clean(e.text) }))

Workaround, and why it is not enough

A timer that polls $.ui.selection(), waits for the engine's copy to land on the clipboard (read with wl-paste) and then writes the cleaned text over it with $.ui.copy.

  • It is racy: pasting right after releasing the mouse still gets the raw text.
  • It polls every 250 ms and spawns a clipboard tool, for something that should be one hook.

Request

Raise ui.copy for the engine's copy on select too (and for /copy, if it does not already), so a plugin can rewrite the text before it reaches the clipboard. Until the selection text itself is fixed (#81472), that would let users fix it for themselves.

Environment

  • Claude Code 2.1.289, "tui": "fullscreen", copy on select on (default)
  • Ubuntu, GNOME, Wayland
  • Ghostty (TERM=xterm-ghostty), no tmux

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗