[BUG] CLI output formatting artifacts break copy/paste - workarounds waste tokens

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/6827
2. https://github.com/anthropics/claude-code/issues/13378
3. https://github.com/anthropics/claude-code/issues/10969

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

👎 This is intentionally a consolidation issue, not a duplicate.

The referenced issues (#6827, #13378, #10969) are fragmented reports of the same root problem - several have been closed as duplicates of each other without resolution.

This issue adds new context not present in any of the others:

1. Token cost analysis - workarounds in CLAUDE.md waste tokens every session across 115k users
2. Adoption context - rapid growth means new users hitting this without knowing workarounds
3. Desktop/Web parity gap - explicit comparison showing CLI lacks copy mechanisms that Desktop/Web have
4. Consolidated evidence - 5 related issues with 50+ combined upvotes proving community scope

The goal is to frame the full problem in one place rather than having it scattered across half-closed duplicates. Please keep this open for proper triage.

Additional case: Backslash line continuation breaks due to trailing spaces

I encountered a related but more severe issue: shell line continuations fail completely when copying multi-line commands.

Reproduction

1. Have Claude output a multi-line shell command with backslash continuations:

``bash
echo "line1" && \
echo "line2" && \
echo "line3"
``

1. Copy and paste into terminal

1. Result:

``
line1
zsh: command not found:
line2
zsh: command not found:
line3
``

Root cause analysis

Using xxd to inspect the pasted content:

000000d0: 22e7 acac e4b8 80e8 a18c 2220 2626 205c  "........." && \
000000e0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000f0: 2020 2020 2020 2020 2020 2020 2020 2020                  
...

The backslash \ is followed by dozens of space characters (0x20) before the newline (0x0a).

In shell, line continuation requires \ to be immediately followed by newline - any characters in between (including spaces) break it.

Workaround

Added a zsh paste sanitizer to ~/.zshrc:

autoload -Uz bracketed-paste-magic
zle -N bracketed-paste bracketed-paste-magic
zstyle ':bracketed-paste-magic' paste-init paste-sanitize
paste-sanitize() {
  PASTED=$(printf '%s' "$PASTED" | sed $'s/\r//g; s/[ \t]*$//')
}

This strips trailing whitespace from each line, fixing the line continuation issue.

Impact

This issue makes it impossible to copy-paste any multi-line shell commands from Claude Code without manual cleanup or client-side workarounds. Combined with the 2-space indent and 80-char wrap mentioned in the original issue, this significantly degrades CLI usability.

+1 — Still hitting this on Windows 11 + Windows Terminal 1.23. Confirmed it's hard newlines in the terminal buffer, not a terminal soft-wrap issue (microsoft/terminal#5113 was fixed in v1.0). Filed #32190 independently before finding this thread.

+1 still happening in Mac OS

I wonder if this is ever going to get addressed.

This is still an issue for me 😢

This is a really frustrating issue.

No matter what I do, I can't get Claude Code to stop adding bullet points and indentation in the chat. e.g. these two lines of code should be at column one:

⏺ import sys
  sys.dont_write_bytecode = True

It adds the bullet point and it adds the fake indentation. Everything I tried, it's as if it can't even see its own mistake, and just keeps repeating this. It even does this if I ask it to "generate code inside triple backtick blocks."

When it's only two lines of code, it's not a big deal, but when it's several lines of code, having to go back and unindent manually Is a needless waste of time.

Some may say, "You're not using Claude Code correctly, you're supposed to just let it edit the code for you," but that doesn't agree with my use case, and it should be a simple fix to have it just not indent the output for no reason, or at least be configurable.

It's very strange that this is "debated" and "various solutions are proposed", when the issue could not be more basic and clear. Here, let me ELI5 it for you.

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.

The fact that this is not obvious, and not immediately fixed since it's such an egregious bug, is quite astounding.

I realize there are fascinating AI conundrums that everyone wants to think about, but the simple stuff still needs fixing.

This is really annoying when you just want to copy out a block of YAML and paste it somewhere. Please add an option to ditch the two leading spaces and line breaks at 80 characters. This is not 1979, most of us have wider terminal windows that can accommodate word wrap.

why isn't this addressed yet? this is such a basic issue! copy pasting output from claude code is surely an incredibly common use case

#18170 describes this issue and has 40 participants (this ticket has 11). Please add a comment there as well so we hopefully get Anthropic's attention by crossing the 50 mark. Thanks.

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

Upvote!

A very simple solution to this was proposed in https://github.com/anthropics/claude-code/issues/43113.

For others arriving here looking for a workaround on macOS — I built a complementary tool: clipboard-cleaner.

It takes a different shape from claude-fix:

• Background daemon running in a Ghostty pane, polling the clipboard every 0.2s
• Auto-detects terminal formatting fingerprints (the 2-space indent + hard wraps from this bug). Plain typing/voice-input is ignored.
• Covers the broad set of paste destinations discussed in this thread and its duplicates: Slack/Discord, GitHub PR/Issue comments, terminal re-paste, Notion/Obsidian, VSCode, plus IMs that don't render Markdown at all (WeChat/Feishu).
• Press 0–9 to grab a cleaned snapshot back to the clipboard.

macOS-only at the moment (pbpaste-based). Hopefully the underlying bug gets fixed upstream so tools like this become obsolete — but until then, sharing in case it helps anyone on this thread.

I find it crazy that people arent more annoyed with this, im having to request claude to create a file so i can copy its output, because formatting breaks stuff. +1 to add an /copy or /noformat

This is a very real pain-point. Submitted feedback, but here to advocate that the cli should be able to un-indent items for copy/paste.....all for the sake of a pretty margin. Ugh.

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.

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.

It worked for me. I switched from default to fullscreen mode (using iTerm2).
I don't quite understand why the "no formatting" option in default mode doesn't fix this, but somehow it does get fixed in fullscreen mode.
But I haven't tested it extensively in fullscreen mode yet, so I'm not sure if there are any side effects.

same issue. copying from cli is pain due to all the spaces.

This seems to have been fixed with 2.1.161 on MacOS. T

Thanks!

This seems to have been fixed with 2.1.161 on MacOS. T

Did you actually test it or did your LLM write that?

It is definitely not fixed as of 2.1.177

Adding empirical confirmation from real Claude Code v2.1.179, since it shows this can't be worked around downstream and has to be fixed here.

The test

I had Claude Code echo one 172-character no-space token in a 90-column tmux pane, then captured the pane two ways: normally (capture-pane -p) and with tmux's wrap-join (capture-pane -pJ).

Rendered output:

⏺ ZSTARTqqqq…qqqq        ← row 1
  qqqq…qqqqZEND          ← row 2, begins with 2 injected spaces

Two hard facts from the capture

• The continuation row begins with a 2-space indent that is not in the original token which means Claude Code inserted it.
• tmux's wrap-join does not reconstruct the token. grep -c 'ZSTART.*ZEND' returns 0 in both the plain and the joined capture. A genuine soft-wrap would rejoin to one line under -J. It stayed split.

So Claude Code emits a hard newline plus a 2-space indent rather than one long line. tmux sees real line breaks, can't join them, and a copy yields ZSTART…\n …ZEND, broken exactly as described.

• COLUMNS is ignored on a real TTY. With COLUMNS=9999 set, Node's process.stdout.columns still reported the real pty width (200), so the env var is not a lever.
• Ghostty has no option to join hard newlines. Maintainer confirmed in ghostty-org/ghostty#11215 that it only joins lines Ghostty itself soft-wrapped and cannot detect application-level wrapping. This makes sense, Ghostty and other terminals shouldn't have application specific interpretation of output.

tmux can't rescue it, Ghostty can't, COLUMNS can't. The fix has to be in Claude Code: emit long lines without inserting \n (and without the 2-space continuation indent) at the wrap width, and let the terminal soft-wrap.

/tui fullscreen solves this issue but that renderer feels so bad. Scrolling is so much slower. It feels much heavier. Bad experience on both: original one feel lighter and faster but has stupid margins and new one does not have margin but feels 2 tons heavier.

+1 that this really needs to be fixed. This is my primary paint point with Claude and I can't believe this has been open for so long without being addressed.