Copy/paste from terminal includes unwanted indentation and trailing spaces

Second this: Linux, native terminal as well as integrated vs code terminal. Still an issue as of today, started at or a little before v2.1.15

am seeing this exact thing, opened a ticket about it, was directed here.

<img width="411" height="197" alt="Image" src="https://github.com/user-attachments/assets/4f45377d-46fa-4acb-9884-798862993122" />

I'm also seeing this.

See: https://github.com/anthropics/claude-code/issues/15199

Please fix this, it's driving me nuts. I have to keep asking Claude Code to generate plan documents when I would much prefer to quickly whip the text out of my Terminal window.

Update in case my setup matters:
My machine is running macOS 14.5. I use built-in Terminal app, currently at version 2.14 (453). Claude Code is running in a Ubuntu 22.04.5 LTS instance, embedded as a VM via Lima (allows me to intrinsically enforce readonly access to my host OS folders).

Also experiencing this on v2.1.19 with gnome-terminal on Fedora 42 (xterm-256color, COLUMNS=120).

Confirming the behavior: lines are padded with spaces to terminal width instead of terminated with newlines. Visually correct, but copy-paste produces single long lines with embedded spaces.

This matches the regression description - padding to $COLUMNS width rather than using \n.

I am also experiencing this with terminal output. There are extra space characters at the end of each line when copying and pasting output into a text file or elsewhere.

Second this: Linux, native terminal as well as integrated vs code terminal. Still an issue as of today, started at or a little before v2.1.15

My workaround for now is in VS code to select two (won't work for 1) of the whitespace characters and then replace all in that document.

I'll give a few more days for Anthropic to fix before investing in a proper fix. I don't want to search/create elaborate fixes if they're already on it.

Experiencing this as well, in Manjaro.
Half solution here is to ask it to copy its reply to the clipboard, that is done without spaces, but it remains extremely annoying.

This is incredibly annoying!

Problem still there with v2.1.29.

For those watching this space: please make some noise on X/linkedin/whatever, because it doesn't seem Anthropic is paying attention to github issues.

Still experiencing this issue. Every line of output has trailing whitespace padding to fixed width, making copy/paste require constant cleanup. This affects all text output, not just code blocks - regular prose, URLs, everything.

Would love to see this fixed or at minimum a 'Copy' button for code blocks that copies clean text.

still experiencing this as well.

This issue exists for me in JetBrains Terminal. However, this has not always been the case and only just started occurring at the time this GitHub issue was created.

This issue does not exist for me when doing the same in Ghostty terminal.

still occurring as of 2.1.31

Same issue on 2.1.32. Very silly issue not allowing clear copy-pasting of multi-lines.

Technical Root Cause Analysis

I dug into the bundled source (cli.js from the @anthropic-ai/claude-code npm package) and identified two distinct sources of the trailing whitespace.

Primary: Ink screen buffer renderer

Claude Code uses a forked version of Ink that renders via a virtual screen buffer — a 2D grid of cells (width × height) where every cell is initialized to a space character (0x20). The function qW7 writes full rows to stdout by iterating over every column in the screen buffer, including trailing empty cells:

for (let D = K; D < Y; D += 1) {
    for (let j = 0; j < O; j += 1, X += 1) {  // O = screen width
        let M = iM7($, _, J, X);  // read cell from buffer
        if (!M) continue;
        dU5(A, M, G);  // emit character — including trailing spaces
    }
    A.txn((j) => [[p_1, HK6], {dx: -j.x, dy: 1}]);  // CR + LF
}

Because empty cells are space characters, every line is padded to the full terminal width with actual 0x20 bytes. Terminals treat these as selectable text on copy.

The fix already exists in the debug rendering path. The getRenderOpsDebug method applies .trimEnd() to each line before emitting it:

getRenderOpsDebug(A) {
    // ...
    for (let z = 0; z < q.height; z++) {
        let w = "";
        for (let O = 0; O < q.width; O++) { /* build line */ }
        K.push(w.trimEnd());  // <-- strips trailing spaces
    }
    return [{type: "stdout", content: K.join("\n")}];
}

The production render() path does not trim.

Secondary: User message padding (mI4)

The mI4 function explicitly pads user-typed messages with spaces to fill the terminal width:

function mI4(A, q, K) {
    return A.split("\n").map((z, w) => {
        let H = w === 0 ? "" : " ".repeat(q);
        let $ = Math.max(0, K - (w===0 ? q : 0) - H.length - O7(z) - 1);
        return H + z + " ".repeat($) + " ";  // pad to width with spaces
    }).join("\n");
}

Suggested fix

The proper fix for the renderer is to emit \x1b[K (CSI Erase in Line) after the last non-space character on each row instead of writing space characters. This tells the terminal emulator to visually clear the rest of the line without inserting actual characters — the standard approach used by curses-based TUIs (vim, htop, nano, etc.).

At minimum, applying .trimEnd() in the production render() path (as getRenderOpsDebug already does) would resolve the copy-paste issue.

For mI4, the space padding can simply be removed — the Ink screen buffer already handles filling the background.

See also #23014 which has comprehensive root cause analysis, xxd evidence, and is properly labeled for triage (bug, has repro, area:tui).

The --debug flag does NOT reach the Ink renderer

Following up on my previous comment — I traced the flag propagation in v2.1.34 and confirmed a disconnect:

• --debug / -d sets _=true in the CLI action handler
• This is passed to the React component: createElement(b91, {debug: _||J, ...})
• But the Ink render options (OY) are created by KXz() → Uw(), which never sets debug:

``javascript
function Uw(A=false) {
let q = G_Y();
let K = {exitOnCtrlC: A};
if (q) K.stdin = q;
return K; // no debug property
}
``

• The hqA renderer receives debug from the Ink instance options (A.debug), not from React props
• So --debug controls app-level debug UI, but hqA.options.debug is always false
• getRenderOpsDebug() (the clean trimEnd() path) is never called in any user-facing configuration

The only place debug:true reaches the Ink renderer is in one internal utility call:

await O9(ht.createElement(CcY, null, A), {stdout: Y, debug: true})

This means adding debug: _||J (or just debug: true) to the render options in KXz()/Uw() would enable the clean rendering path — though with whatever other side effects debug mode has on rendering (no throttling via j4A/debounce, etc.).

Still an issue in Claude Code v2.1.39 on Ubuntu 24.04 using default gnome-terminal.

This is a particularly annoying problem when I'm trying to copy+paste long commands that have escaped (\) newlines. It ends up running each line of the command in the shell independently, which has the potential to do bad things.

funky workaround: make claude code remember to "copy any cli to clipboard after displaying". make it use wl-clipboard. Wont solve all problems and rather unelegant. But solves 90% of my problems with copy paste since I rarely want to copy paste anything other than CLI commands.

Yea luckily this works now, but it didn't recently when this issue really affected me. Back then having it write to file to copy resolved it when copy to clipboard and manyual copy from session didn't work

Same issue in Debian, Claude 2.1.42

This is really bad especially compared with opencode that autoamtically copy the selected text with a nice feedback as modal.

Imagine working with Kubernetes manifest and yaml files. Same for python...

omg this is so annoying, how to fix?!?!?!

lso hitting this on Windows 11. Copying multi-line az CLI commands from output results in broken commands when pasted.
The root cause analysis and fix in #23014 looks solid — would love to see this land.

It's a tale as old as software development itself (probably), that companies present to the world as "open source" but it's a masquerade in truth. The carefully crafted and well-meaning issues on this repository bear no signs of interest or care from Anthropic, I think we're all just shouting into the void. I'm sure they do have very clever people, developers and delivery managers alike, but I'm also sure they're imbued with enough arrogance and/or corporate-vision so as not to really listen to us little people. They're also probably overwhelmed with the quantity of inbound, amidst this crazy gold rush. It's exciting times for tools like this but I don't believe for a second that individual users like us (the "community") will change a jot of what comes out of the factory. I'm going to unsubscribe from this issue, it's honestly just another form of doom scroll. This might get fixed in time, but in the meantime I'm just going to daily adjust and cope with the current state of play, like we all do. 🤓

Hit this today — Claude Code output a shell script in a code block, and when I copied it into a Keyboard Maestro macro, every line had 2 leading spaces. The #!/usr/bin/env bash shebang became #!/usr/bin/env bash, which silently breaks script execution since the kernel requires #! at byte offset 0.

Using Warp terminal on macOS.

I see this issue as well. Claude is doing the heaving lifting of writing the command but (in the noble name of making the GUI more readable) adds spacing and comments that require the command to manually edited to remove the extra formatting characters.

Anthropic is obviously ignoring github issues. For those of you on X/reddit/whatever, making some noise there might be the only way to get this fixed.

The funny thing is that this is trivial to fix and test. See my analysis (well, Claude Code's analysis) here: https://github.com/anthropics/claude-code/issues/23014#issuecomment-3862802903

Agreed with @adereis - feels like they aren't monitoring this.

You can also submit a bug from directly within Claude Code with /bug. I'll submit one and if enough of us do it, it may generate some sort of issue in Anthropic's internal ticketing system.

As seen from the handling of https://github.com/anthropics/claude-code/issues/16497, Anthropic notices some issues, and even fixes them, but avoids to respond publicly.

The repo has also an "oncall" labeling bot. If you comment on the issue right before the bot runs, it will use AI to evaluate whether the issue is worth adding the label. Only issues judged by AI as blocking get the "oncall" label, and such issues may get some more attention from Anthropic (but typically still no public response) https://github.com/anthropics/claude-code/issues/21953

For this issue the evaluation happened in https://github.com/anthropics/claude-code/actions/runs/21917530585 following this comment https://github.com/anthropics/claude-code/issues/18170#issuecomment-3886083081, and the AI bot has not explained why "oncall" label was not added.

<img width="1409" height="512" alt="Image" src="https://github.com/user-attachments/assets/1f699ff3-d24c-4a48-98f5-65d0fbba084f" />

This is going on for a while, please fix.

@marcindulak thanks for sharing the on-call report, this is good to know!

Lack sufficient engagement (< 50 comments + reactions) to indicate widespread critical impact

One problem is that this issue has several duplicated reports that keep being closed for lack of engagement, and this one is not even triaged as a bug for some reason.

We need to ask for more people to jump in here and leave a comment, even if it's just a +1.

What's funny is that any bot would realize that this affects everybody who uses Claude Code.

Probably one of the easier fixes too, but I can't say that with certainty.

I am here to say that this is also driving me crazy.

Nothing screams "You just copy and pasted this from claude-code" louder than these indents and line breaks. I would like them gone please. I like to workshop documentation with claude until it is perfect and these formatting weirdnesses make my work look lazy.

Workaround for Kitty users

Adding strip_trailing_spaces smart to ~/.config/kitty/kitty.conf mitigates the trailing whitespace on copy-paste. The smart mode strips trailing spaces from selections when they appear on all lines — which matches exactly the pattern produced by the Ink renderer's space-padding.

Tested on Fedora 42 with Kitty 0.43.1.

This is a terminal-side workaround only. It doesn't address the root cause (writing 0x20 instead of \x1b[K), and doesn't help users on gnome-terminal, VS Code, Warp, JetBrains, or macOS Terminal. The proper fix remains in the renderer, as described in #23014.

This is blocking core functionality, not just a UX annoyance. Claude Code's primary value proposition is generating commands and code that users then run. If those commands can't be reliably copy-pasted, that workflow is broken. The 2-space indent and hard line wraps are literal characters emitted into stdout, and they silently corrupt shell commands in ways that are hard to debug. In my case, a udev rule with leading whitespace was silently ignored by the kernel with no error message. Any heredoc, multi-line command, or line continuation (\) is affected.

This has been reported at least 5 times (#859 with 37+ upvotes, #6827 with 13 upvotes, #13378, #5097, #4686), and the community has resorted to workarounds like the claude-fix pip package and zsh paste sanitizers. Neither is adequate - they add friction to every interaction and don't address the root cause.

Comparing Claude Code to OpenCode (another AI coding CLI) makes the problem and the fix both clear. OpenCode renders code blocks as proper TUI panels - bordered boxes drawn with ANSI cursor positioning. Terminal selection captures exactly the characters at those cell positions, so you get clean code with no artifacts. Claude Code, by contrast, renders everything as a flowing text stream with formatting baked in as literal characters, which the terminal has no way to strip on copy.

Since Claude Code is Node.js/TypeScript, frameworks like Ink (React for CLIs) or blessed already support positioned rendering. Writing code block content to specific cell coordinates rather than as indented text in a stream would make copy-paste just work.

I don't understand how Claude can create proper markdown ticks for code but Claude Code, which literally is used for coding, cannot. I have to manually edit every script in vim or every paragraph that's misformatted. Wild stuff. Please fix.

/copy

via https://github.com/anthropics/claude-code/issues/859#issuecomment-3939555004

This is critical and very annoying. Please fix.
It has been running on for months now.

I wonder why the claude code team does not experience this firsthand ?

It's particularly annoying when using Claude through SSH as /copy won't work. The worst case I've come across is when you want to sign in and the long URL is split intro multiple lines. The terminal app won't detect it as a wrapped long URL and you can't ask Claude itself to write it to a file.

+1. Yes, this is critical impact. Not like Anthropic cares though. They're too busy paying Linkedinfluencers to shill for them

Reconfirming this affects macOS too. My setup is macOS 26.3 + iTerm2. This is such an obvious problem that hampers the experience quite a bit.

For added context, I do not think this affects just the terminal. We have a skill that rewrites/updates Jira descriptions for us and newlines have extra spaces there as well.

+1

+1

+1

+1

plz made the bad space characters stop 🐱

+1

Anthropic really needs to look how copy/paste is done in OpenCode. It works incredibly nice in there. You don't even need to press ctrl+c either, or if using WSL2, you don't need to right-click to copy. You just highlight content and it copies it. This would ideally be a configurable toggle though (default on, is likely best).

But the way theirs works and fixes all the formatting issues (like leading tabs, spaces, and new lines) is great.

+2

this command unblocked me: /copy

---
description: Copy last response to clipboard (no trailing spaces)
allowed-tools: Bash(pbcopy:*), Bash(xclip:*), Bash(wl-copy:*), Bash(clip.exe:*)
---

Copy your most recent complete response to the system clipboard.

Use the correct clipboard command for the platform:
- macOS: echo -n "content" | pbcopy
- Linux/Wayland: echo -n "content" | wl-copy
- Linux/X11: echo -n "content" | xclip -selection clipboard
- Windows/WSL: echo -n "content" | clip.exe

Write the content of your last response to a temp file first, then pipe to clipboard.
Use printf to avoid echo interpretation issues. Do NOT re-render via TUI — write directly
via the Bash tool to avoid trailing whitespace from the Ink renderer.

After copying, confirm: "Copied to clipboard."

this command unblocked me: /copy --- description: Copy last response to clipboard (no trailing spaces) allowed-tools: Bash(pbcopy:), Bash(xclip:), Bash(wl-copy:), Bash(clip.exe:) --- Copy your most recent complete response to the system clipboard. Use the correct clipboard command for the platform: - macOS: echo -n "content" | pbcopy - Linux/Wayland: echo -n "content" | wl-copy - Linux/X11: echo -n "content" | xclip -selection clipboard - Windows/WSL: echo -n "content" | clip.exe Write the content of your last response to a temp file first, then pipe to clipboard. Use printf to avoid echo interpretation issues. Do NOT re-render via TUI — write directly via the Bash tool to avoid trailing whitespace from the Ink renderer. After copying, confirm: "Copied to clipboard."

As @manuelmorales mentioned above, doesn't help when you're ssh-ing to another machine. Also doesn't help when it gives you several long commands you need to run by yourself, the commands are split into two or more lines and you need to run them one by one. Or when you have to login to your ssh instance and the login link gets broken into multiple lines.

Can't believe this is still an issue.

if output is supposed to be strictly formatted; then
  don't add indenting and hard line breaks
done

This is highly annoying when you just need to copy a bit of YAML or Python. Please add an option to remove the leading two spaces and line breaks at 80 characters.

I believe this wasn't an issue with the NPM variant earlier this year. It makes things annoying when working with infrastructure on another server that I don't want to give claude access to and I need to copy commands etc back and forth.

running into this as well, very frustrating to have to copy each line individually or copy/paste into another program to clean up the output from claude

Please ask your colleagues to come here and leave a comment. Apparently 50+ participants is what brings a ticket to Anthropic's attention. We're at 40.

And for us here, let's also add a comment to these other three, all describing the same issue or small variations: #15199, #13378, and #6827

(for some reason this ticket here is not triaged as a bug, so it might be ignored for longer)

This is severely impacting my productivity and it seems like such a simple thing for fix on face value.

This seems like a fairly low effort, high impact fix.

I know this is just an opinion, but I'm surprised this terminal app is so un-terminal. Easy copy pasting of plain text are things I take for granted.

Still waiting for this fix thanks!

Surprised this is still an issue. It's a TUI not respecting all the rules that come along that fact. The /copy command is a nice remedy for some cases but shouldn't be needed in the first place. I understand its usability for long responses but for anything else, a simple highlight-and-copy should work out of the box.

Exactly. They had to add complexity to solve a problem introduced by unnecessary complexity.

Dealing with this issue every single day. /copy command does help, but it's much more work than selecting a few specific lines from the whole output with mouse and copying them as we all do in all other tools. It is indeed surprising how CC gets daily releases with 20-40 bugfixes or "18mb startup memory reduction", but this issue affecting so many users is not on their radar. The most frustrating part is that the issue is inconsistent - it may butcher the whole output, or some part of it, or nothing at all (see the screenshots).

Platform: MacOS
Terminal: Kitty, Ghostty, iTerm2, WezTerm, Terminal.app
CC version: 2.1.80

<img width="280" height="283" alt="Image" src="https://github.com/user-attachments/assets/3290fe11-4ceb-48d2-854e-ddce9f231765" />

<img width="270" height="266" alt="Image" src="https://github.com/user-attachments/assets/08f58f79-2aa3-48ef-9c40-312353a2e434" />

<img width="536" height="284" alt="Image" src="https://github.com/user-attachments/assets/73e67649-7535-4041-81cd-7718bcb9b92e" />

The TUI is built in such a way that this sequence of actions is broken:

• using your mouse, highlight a fragment of text
• copy the text (Ctrl+C, etc.)
• paste the text anywhere else (a text editor, another terminal, etc.)

Expectation: the pasted text should be identical to the copied text.

Reality - the pasted text is completely broken:

• there are characters trailing after the end of each line
• there are extra characters ahead of each line
• it's unreadable to humans
• it's a waste of tokens for agents
• if it's code, it's usually broken
• happens on every OS where Claude Code runs

This is pretty simple stuff. Copy/paste text from an app is something users take for granted.

Code literally writes itself these days, so one would expect a simple but important bug like this would be fixed right away, no?

Or how about this? Would it be possible to make the default left indentation customizable at least? Might not solve the trailing spaces problem, but will at least solve a portion of the problem with relatively little work?

Ghostty user here. Claude Code inserts hard newlines for word wrapping instead of letting the terminal handle soft wrap. This makes copied text unusable — especially code snippets and terminal output get broken line breaks when pasted. Terminal-native soft wrap would solve this cleanly. This is a daily friction point for anyone using Claude Code in a narrower terminal window.

Please make the indentation customizable and remove the hard-wrap! I don't want to use /copy and then delete the 90% of the response that I'm not interested in. I want to use tmux to copy the text that I am interested in the way that I do in all of my other terminal applications.

1+ here as well. very frsutrating.

Voicing my issue with this as well.

Same here, very annoying!

+1 Extremely annoying!

As a workaround in kitty, I've been playing around with the pass_selection_to_program action (see https://sw.kovidgoyal.net/kitty/conf/#shortcut-kitty.Pass-selection-to-program), for instance binding the script below to shift-command-c in kitty.conf: map cmd+shift+c pass_selection_to_program ~/.config/kitty/fix_claude_indent.sh

```bash ~/.config/kitty/fix_claude_indent.sh
#!/bin/bash

Fix Claude Code output indentation: detect indent from line 2

and strip that many leading spaces from all lines except the

first (also remove trailing spaces from all lines, then copy to

clipboard. Used via kitty's pass_selection_to_program action.

indent=$(sed -n '2s/^\( \)./\1/p' <<< "$1" | wc -c)
indent=$((indent - 1)) #number of leading spaces to be removed
pad=$(printf '%*s' "$indent" '') #leading space to be removed
sed -e 's/[[:space:]]*$//' -e "2,\$s/^${pad}//" <<< "$1" | pbcopy

Then, when selecting a multi-line python or shell command in Claude Code, it should remove the leading N spaces (such that the second line in the selection has zero leading spaces) and all trailing whitespace, then you can paste as usual. Not perfect, but workable until a real fix is available.

PS: The script above uses GNU sed, it likely works with BSD sed as well.

I would like to see this fixed as well.

Please fixe it. Please.

+1

As a workaround I added following instruction to ~/.claude/CLAUDE.md

For multi-line shell commands, write to /tmp/cmd.sh then cat /tmp/cmd.sh | pbcopy so the user gets clean clipboard content. The terminal renderer breaks copy-paste on code blocks (adds indentation/trailing spaces).

As a workaround I added following instruction to ~/.claude/CLAUDE.md For multi-line shell commands, write to /tmp/cmd.sh then cat /tmp/cmd.sh | pbcopy so the user gets clean clipboard content. The terminal renderer breaks copy-paste on code blocks (adds indentation/trailing spaces).

For multi-line shell commands(Linux), write to /tmp/cmd.sh then cat /tmp/cmd.sh | xsel --clipboard --input so the user gets clean clipboard content. The terminal renderer breaks copy-paste on code blocks (adds indentation/trailing spaces).

Workaround for Mac users with Raycast:

You can set this up as script command with a hotkey, I just use shift + command + v to paste clean content:

#!/bin/bash

# Required parameters:
# @raycast.schemaVersion 1
# @raycast.title Squeeze Paste
# @raycast.mode silent

# Optional parameters:
# @raycast.icon 📋
# @raycast.packageName Clipboard

# Clean the clipboard in-place
pbpaste | tr -s ' ' | sed 's/^ *//;s/ *$//' | pbcopy

# Simulate Cmd+V to paste into the focused app
osascript -e 'tell application "System Events" to keystroke "v" using command down'```

+1 Extremely annoying!

Additional use case: Generated text for copy-paste (e.g., Slack messages)

I'm experiencing a related but slightly different scenario. When I ask Claude Code to generate text intended for copy-paste — for example, "write me a Slack message to my team explaining the pain points of this strategy" — the output contains many unnecessary empty spaces throughout the text.

Steps to reproduce

1. Ask Claude Code to generate a message or text block meant for external use (Slack, email, docs, etc.)
2. Copy the generated text
3. Paste it into the target application

Observed behavior

The pasted text contains excessive whitespace — not just leading indentation or trailing spaces, but unnecessary empty spaces scattered within the content. This requires manual sanitization before the text is usable.

Impact

This defeats the purpose of generating ready-to-use text. Every generated message needs a cleanup pass to remove extra whitespace before it can be shared, which adds friction to one of the most common use cases: quickly drafting text for communication tools.

Environment

• Platform: macOS
• Terminal: CLI

This is a terminal-side issue — Claude Code's TUI uses indentation for visual alignment, and terminal copy includes those whitespace characters.
Workaround 1 — Use tmux copy mode with trimming:

set -g @copy_mode_yank "pbcopy"
bind-key -T copy-mode-vi y send-keys -X copy-pipe-and-cancel "sed 's/^[[:space:]]*//' | sed 's/[[:space:]]*$//' | pbcopy"

This strips leading/trailing whitespace when copying from tmux.
Workaround 2 — Clipboard post-processing:

alias clipclean='pbpaste | sed "s/^[[:space:]]*//" | sed "s/[[:space:]]*$//" | pbcopy'

After copying from Claude Code, run clipclean to strip the indentation.
Workaround 3 — Have Claude write to file instead:

<!-- CLAUDE.md -->
When I ask you to show code, write it to a file instead of printing it inline.
Use the Write tool to create a temporary file, then tell me the path.

Copying from a file in your editor won't have the TUI indentation artifacts.
Workaround 4 — Terminal-specific settings:

• iTerm2: Edit → Selection Respects Soft Boundaries → enable this. Also try: Preferences → Profiles → Terminal → check "Trim trailing whitespace on copy"
• Ghostty: May handle this differently — test with rectangular selection (Alt+click drag)
• Kitty: strip_trailing_spaces smart in kitty.conf

Workaround 5 — VS Code extension:
The VS Code Native UI mode renders output differently and may not have this issue. Code blocks in the VS Code webview are copyable without the terminal indentation.

huge upvote. this is the ONLY reason I still use Cursor instead of ClaudeCode.

If you are on a mac, try using: https://prettypaste.interappy.io/
I got frustrated with the same thing and created this to get around the bad line breaks, bullets, numbers etc.
(even works with the | tables claude code creates when pasting into Google docs, turns it into HTML table)

You just need to tell claude code

/copy

and it lets you copy the codeblock cleanly

Latest update is even worse. They now add a unicode character for instance:
● ansible-playbook -i inventories/sco.yaml --limit proxy-beelink-001 playbooks/setup_traefik.yaml

So now it does not workat all evenf for shell commands. And whitespace detection is .. not enough.

For multiople lines only the first one has the dot. The others don't.

Confirmed on Windows 11 + Windows Terminal + PowerShell 7 (Claude Code v2.1.96)

TL;DR: Hard wraps + trailing spaces on all output. No config to disable. /copy works as workaround, but on Windows/PowerShell accents break — fix with [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 in $PROFILE.

What I see

All prose output (not just code blocks) has hard newlines inserted at the terminal column width (~132 cols). When pasting into VS Code, a browser form, or any other app, every wrapped line becomes a real line break. This makes it impossible to copy-paste text meant for external use (email drafts, form fields, client messages, etc.).

Separately, lines are padded with trailing spaces to the full terminal width (the 0x20 buffer issue described by @adereis).

What I tried to fix it (none of it works)

| Attempt | Result |
|---------|--------|
| $env:COLUMNS=10000 before launching Claude | No effect — Claude reads PTY size directly, ignores env var |
| trimBlockSelection: true in Windows Terminal settings.json | No effect on the hard wraps |
| Ctrl+Shift+C instead of right-click copy | Same result |
| Resize terminal wider, re-copy | Line breaks move to new column boundary, confirming they're generated at render time |
| tput cols / stty size from within Claude's bash | Reports 80 or empty — Claude uses its own PTY size detection, not shell env |

Workaround that works: /copy

The /copy slash command copies the last response to clipboard without the hard wraps and trailing spaces. Content is also written to a temp file ($env:TEMP\claude\response.md).

Gotcha for Windows/PowerShell users: broken accents

If you use /copy on Windows with PowerShell, accented characters (è, é, à, etc.) will be garbled in the clipboard (è becomes è). This is because PowerShell defaults to CP-1252 encoding, not UTF-8.

Fix: Add this to your PowerShell profile (notepad $PROFILE):

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8

Restart the terminal after saving. Accented characters will then copy correctly.

My use case (underrepresented in this thread)

I use Claude Code to draft text for external consumption: form answers, client emails, SMS messages, freelance platform responses. The generated text is meant to be copy-pasted verbatim into a browser or another app. Hard wraps break every single one of these workflows. /copy works but adds friction to every interaction — this should just work on normal copy-paste.

This isn't only about code indentation — it's about all prose output being corrupted on copy.

Environment

• Claude Code v2.1.96
• Windows 11 Pro (10.0.26200)
• Windows Terminal (default, latest)
• PowerShell 7.x (pwsh.exe)
• Terminal width: ~134 columns

If you are on a mac, try using: https://prettypaste.interappy.io/ I got frustrated with the same thing and created this to get around the bad line breaks, bullets, numbers etc. (even works with the | tables claude code creates when pasting into Google docs, turns it into HTML table)

Please no one download this. Not open source. Brand new account with single commit. You're trusting this app with the contents of your clipboard.

If you are on a mac, try using: https://prettypaste.interappy.io/

AI is amazing. We can vibe-code apps to work around bugs in other apps! /s

Since this is a popular issue, can someone from Claude at least respond or give some kind of reaction on if this is being worked on?

same issue in Ghostty on macOS, affects both prose and code blocks

@jmroon understand your hesitancy around this. It's truly what @FlorinAndrei said... I hit the frustration and vibe coded a solution. Sharing so that others can benefit too. Its signed and notarized app through Apple.

For what it’s worth, i’ve been making due with Claude’s

/copy

And in the case I’ve copied too much, or generally just want to edit what on my clipboard with vim:

pbaste | vipe | pbcopy

It could easily be mapped to a key to launch an overlay/window if you want it part of your flow.

Immensely annoying, please give us some options here.

+1, really annoying especially for Python code

Also, thought I should mention that Codex doesn't have that problem.

Codex doesn't have that problem.

Applications written in the 1980s didn't have this problem.

Had the same annoyance so I built a small menu-bar app that fixes it on the paste side: https://github.com/retention-corp/openpaste

It reads the clipboard, rejoins terminal-wrapped lines (Korean too), strips prompt/heredoc wrappers and trailing spaces, preserves lists/tables/code/diff blocks, and optionally flattens to one line for Notes/Docs/Slack. macOS only, ad-hoc signed, no network calls — the whole formatter is one Swift file you can read in one sitting. Until Claude Code ships a real fix, this takes the manual cleanup out of the loop.

Please fix this! It's incredibly frustrating.

I did find a bit of a workaround in MinTTY (on cygwin) though:

Enable "Rewrap on resize" in Mintty (Options > Window) and resize the terminal window after output completes. This causes Mintty to reflow the text, stripping the space-padding inserted by the ink renderer. Copied text is clean after the resize.

simple fix, lets do it.

This is an ongoing irritation with using the program. I waste a lot of time editing output. My workaround is to ask for a markdown block. I'll try /copy. Please fix.

I paste into the Claude chat interface and ask it to correct formatting. This is a huge waste of time and resources.

I fail to see why this is not configurable. Seems pretty easy to just give us a way to turn off all indenting in the Claude code window ...easy fix.

I found quite a nice solution to this problem:

1. Install BetterTouchTool
2. Create a new trigger System Clipboard Contents Did Change
3. And trigger action Transform Clipboard Contents with Java Script
4. And for transformer code, use the following

async (clipboardContentString) => {
    // Workaround for anthropics/claude-code#18170 + chat-frame gutter.
    // 1. Strip trailing padding (lines padded to $COLUMNS).
    // 2. Dedent: remove the smallest common leading whitespace.

    const stripped = clipboardContentString.replace(/[ \t]+(?=\r?\n|$)/g, '');

    const lines = stripped.split('\n');
    const nonBlank = lines.filter(l => l.trim().length > 0);
    if (nonBlank.length === 0) return stripped;

    const minIndent = Math.min(
      ...nonBlank.map(l => l.match(/^[ \t]*/)[0].length)
    );
    if (minIndent === 0) return stripped;

    return lines.map(l => l.slice(minIndent)).join('\n');
};

<img width="1509" height="843" alt="Image" src="https://github.com/user-attachments/assets/e8398505-dc99-4467-bd2e-c5145d16c97b" />

@d-mankowski-synerise I don't suppose you know of a solution that works for Windows and/or Linux? I'm not sure I'm interested in paying for software to fix a bug in another software -- but, I might consider it.

Will not use Claude Code until this is fixed.

Another issue is that long link in Claude code is broken in Windows terminal, because the indentation.
Can we have a setting to remove them?

<img width="1898" height="393" alt="Image" src="https://github.com/user-attachments/assets/c954bc16-a742-4645-a418-cd0ddeaf4426" />
I am curious if they ever use their claude agent to analyse and prioritise similar issues. This one has already got 2xx thumbs ups.

I think it was fixed :)

Just tested on 2.1.141 and still broken, multi line snippets have a 2 space indent after first line

Should be a trivial fix and yet its been 5 months and not even a response 🤕
I mean can't they just use the culprit himself (Claude) to fix his crimes?

Well, I'm running version 2.1.141 on my Mac, via iTerm2, and it is fixed.

<img width="931" height="388" alt="Image" src="https://github.com/user-attachments/assets/9aad792d-0f2a-4b7a-b526-ba78549ced0b" />

Well, I'm running version 2.1.141 on my Mac, via iTerm2, and it is fixed. <img width="931" height="388" alt="Image" src="https://github.com/user-attachments/assets/9aad792d-0f2a-4b7a-b526-ba78549ced0b" />

How does that work? I'm surprised by it because I can still see the padding in the screenshot. But the selection avoids it. Is that an iTerm feature?

> Well, I'm running version 2.1.141 on my Mac, via iTerm2, and it is fixed. > <img alt="Image" width="931" height="388" src="https://private-user-images.githubusercontent.com/29309383/593511531-9aad792d-0f2a-4b7a-b526-ba78549ced0b.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Nzg5MjUxODAsIm5iZiI6MTc3ODkyNDg4MCwicGF0aCI6Ii8yOTMwOTM4My81OTM1MTE1MzEtOWFhZDc5MmQtMGYyYS00YjdhLWI1MjYtYmE3ODU0OWNlZDBiLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA1MTYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNTE2VDA5NDgwMFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWQwNGRmN2ZjZjZlZTMyNzIyODZmMmRiN2M4YjBmOTlmNGI4YjFmNmU1NjJkY2MwZDQ4MjAyNTkyYzM2OGJmZjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.S2igcbHijK3cXs-4hbOxIgQmcm1nTSRODDIf-sgWMw0"> How does that work? I'm surprised by it because I can still see the padding in the screenshot. But the selection avoids it. Is that an iTerm feature?

I don't think so; it didn't work beforehand, and I didn't change anything.

I can confirm that with my setup (where I'm using claude code within tmux) that if I enable tmux mouse mode and then use the mouse to select text then the indentation is not selected. But if I use tmux copy-mode to copy text then the indentation is included (although I have an Alfred.app workflow that can strip it out for me).

But what I haven't figured out how to do is copy multiple "pages" of content via the mouse.

It kinda feels like some of you are doing block selects, which selects a 2D area of the terminal, and not basic line based selects. Or your terminal has features that the ones I tested (ghostty, kitty, wezterm, alacritty) don't have...

If claude didn't introduce the problem then none of this hoop jumping would be necessary...

Just tested on latest Claude Code using iTerm2 and finally, mouse copied output doesn't contains spaces. It did paste cleanly in an IDE editor, no formatting issue at all! 🎉

Fought this for a couple of hours, apparently Claude Code on terminal has 2 modes:

• default (enable with /tui default) - no formatting, just raw output to the terminal, terminal deals with selection and copying.
• fullscreen (enable with /tui fullscreen) - takes over mouse events, properly formats selections.

Hope it helps.

fullscreen works for me on linux+ghostty, thanks!

It manages the selection correctly and triggers a copy via OSC52 sequences

edit:
It seems that fullscreen mode doesn't allow middle click paste... why does basic terminal functionality need to be broken???

This looks to have been fixed with 2.1.161! 🥳

This looks to have been fixed with 2.1.161! 🥳

Not in Linux :(

The core ask is simple: use soft wrapping for code block content only — emit long lines without inserting hard \n
characters, and let the terminal emulator handle visual wrapping. The TUI chrome (spinners, separators, progress
bars) can keep using terminal width — only code block text needs to change.

Why this matters:

• Hard \n in code blocks makes every long command broken on paste — you get a multi-line mess with indentation

artifacts instead of a runnable one-liner

• There is no workaround that doesn't destroy something else — setting stty cols 300 breaks the entire TUI layout;

/copy works but requires an extra step every single time

• tmux users, iTerm2 users, and terminal users on every platform are all hitting this — see also #42296 (closed as

not planned, same root cause)

The fix is surgical: don't call the hard-wrap renderer for fenced code block content. Emit the raw line and let the
terminal wrap it visually. This is standard behavior for every other terminal tool that outputs code.

Fought this for a couple of hours, apparently Claude Code on terminal has 2 modes:

default (enable with /tui default) - no formatting, just raw output to the terminal, terminal deals with selection and copying. fullscreen (enable with /tui fullscreen) - takes over mouse events, properly formats selections. Hope it helps.

/tui default, works for me

Please see: https://github.com/anthropics/claude-code/issues/18170#issuecomment-4497316086

latest iterm2, either /tui mode-- both copy paste and link clicks are broken if the wrapping boundary is tmux instead of iterm2 itself. Should work regardless of if it's an iterm2 pane or a tmux pane that causes the wrapping. Also, links should be OSC 8 hyperlinks (I think they _sometimes_ are but not always, which drives me nuts).

My workaround:

• Log details to /tmp/claude.log via Claude Code hooks
• Keep tail -f /tmp/claude.log in a separate terminal tab

This makes it nearly impossible to authenticate MCP servers across remote ssh sessions. Please fix ASAP.

As a work-around, you can use /copy to copy the text to the clipboard.

Or if you know you'll want it copied (or just a specific part), you can whitelist the copy to clipboard tool and instruct claude to also copy to clipboard.

Confirming this reproduces cleanly and is terminal-agnostic — tested in Terminal.app, iTerm2, Ghostty, and Cmux, all on macOS, same result in every one.

Repro:

1. Open a terminal and start Claude Code.
2. Ask it to generate one paragraph of 26 words, one starting with each letter of the alphabet, then print that paragraph 10 times, each prefixed with "paragraph N" (10x is enough to overflow a default window size and force scrollback).
3. Select/copy all 10 paragraphs by clicking and dragging (scrolling while the selection is active, since the content overflows the viewport).
4. Paste into a plain text editor.

Result: Every terminal drops something on paste — e.g. missing the words starting with g–j in one of the paragraphs, or a run of words silently vanishing mid-line (see screenshot: paragraph 7 loses "great happiness inside;" and part of "near open porches," between "feel" and "kittens").

Since the same corruption shows up across four completely different terminal emulators/renderers with the same test, this points to Claude Code's own output (hard-wrapped lines / redraw during scroll) rather than any individual terminal's mouse-selection handling — consistent with the hard-newline wrapping theory already discussed in this thread.

Hope this is a minimal, (almost)deterministic repro since most reports in this thread are "intermittent" or "hard to reproduce"

<img width="1590" height="256" alt="Image" src="https://github.com/user-attachments/assets/329e7f6d-f255-4187-be0e-6cd004add066" />

This makes it nearly impossible to authenticate MCP servers across remote ssh sessions. Please fix ASAP.

I do not understand why, but on iterm2 this is the one case that, even though clicking of the link is broken, if I copy paste it into my browser, it works spaces or not.

I have not checked if something is removing the spaces or if the link is strangely resilient to spaces in the locations that it's happening on my terminal size.

Still no word from Anthropic re a timescale for a fix? What on earth is going on, this costs me so much time currently

We're all talking into the void, expecting the AI to notice, lol.

So frustrating. Ideally, I just want to triple click in iTerm to get the full command, copy, paste, run.