[FEATURE] Terminal selection includes trailing cell-padding whitespace — clipboard pollution on copy

Resolved 💬 3 comments Opened May 1, 2026 by iNiKe Closed May 5, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

## Summary

When I select rendered output in the Claude Code CLI terminal and copy it to
the clipboard (Cmd/Ctrl+C, right-click → Copy, etc.), every line is padded
with the spaces that the terminal used to pad cells out to the column width.
Pasting the result into another editor leaves a long whitespace tail on every
line that I have to clean up manually before I can use the snippet.

This happens for any selection — assistant prose, tool output, diff blocks,
file contents printed by Read — basically anything that is rendered to
the screen.

## Steps to reproduce

  1. Run claude (interactive) or any session that produces multi-line output

wider than ~40 columns but narrower than the terminal width.

  1. Select 2-3 lines with the mouse.
  2. Cmd+C / Ctrl+C / right-click → Copy.
  3. Paste into any editor, e.g. VS Code, Notion, a chat input, etc.
  4. Observe the trailing whitespace on every copied line.

A minimal example: ask Claude to print a numbered list. Each list item line
ends up padded to the terminal width in the clipboard.

## Expected behaviour

Copied text should have trailing whitespace trimmed per-line, matching the
behaviour of iTerm2, Terminal.app, Alacritty, WezTerm and most modern
terminal emulators (which strip cell-padding whitespace on copy by default,
or expose a trim trailing whitespace on copy setting that is on by
default).

## Actual behaviour

Each copied line carries a trailing run of spaces equal to
(terminal_columns - visible_line_width). Pasting it produces text like:

  • first item
  • second item
  • third item

instead of:

  • first item
  • second item
  • third item

## Environment

  • Claude Code CLI version: <fill in claude --version output>
  • OS: <macOS / Linux / Windows + version>
  • Shell: <zsh / bash / fish + version>
  • Terminal emulator (if any wraps Claude Code): <e.g. iTerm2 3.5, Apple Terminal, Alacritty, WezTerm, Windows Terminal, Ghostty>

Note: I see this even when the host terminal emulator has its own
"trim trailing whitespace on copy" setting enabled, because Claude Code
appears to control the selection rendering itself rather than deferring
to the host terminal's selection layer.

Proposed Solution

If Claude Code uses xterm.js / a custom selection layer internally, the
copy path can intercept the copy event and post-process the selection
before it reaches clipboardData:

``js
host.addEventListener('copy', (e) => {
const sel = terminal.getSelection();
if (!sel) return;
const cleaned = sel
.split('\n')
.map(line => line.replace(/[ \t]+$/, ''))
.join('\n');
e.clipboardData.setData('text/plain', cleaned);
e.preventDefault();
}, true);
``

(or the equivalent in whatever rendering layer Claude Code uses).

A configuration toggle would also work — e.g. trimSelectionWhitespace
in the user settings, defaulting to true. But trimming by default is
the behaviour every other terminal I use ships with, so I'd argue for
making it the default rather than an opt-in.

Alternative Solutions

Workaround I'm using today

Piping the clipboard through pbpaste | sed 's/[[:space:]]*$//' (macOS)
or a small browser extension when copying from the web app. Neither is
ergonomic for an interactive CLI tool I use dozens of times an hour.

Thanks!

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗