2-space indent and hard wrap at 80 breaks copy-paste - Need a way to configure it out of the way

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/6827
2. https://github.com/anthropics/claude-code/issues/7670
3. https://github.com/anthropics/claude-code/issues/12734

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

It's a somewhat different idea how to deal with the same problem.

``--no-indent, --no-wrap, etc.``

I also have this issue. Im on macos. Very frustrating

+1 Same issue here.

• OS: macOS
• Terminal: iTerm2 3.4.16
• Claude Code version: 2.1.7 (Claude Code)

The 2-space indentation makes copy-paste unusable. Would appreciate a config option to disable it.

This is super unuseful if you NEED to copy paste shell scripts, because claude code is not allowed to connect to other machines.

Simple change would be: Output code as is. No formating. Or it would be useful if the indentation could be turned off when you copy text from the terminal... or something which cleans up the copied text.

/copy is a good partial workaround for right now:

Usage

<details><summary>Expand</summary>
<p>

<img width="1000" alt="Image" src="https://github.com/user-attachments/assets/556f7b60-3ea8-477b-91a9-acd1f7d523d3" />

Before

---

⏺ /copy was added in Claude Code v2.1.59 (February 26, 2026). It copies the last
  assistant response to your clipboard — and if the response contains code blocks, it
  opens a picker to choose which block (or the full response) to copy.

  That's actually relevant to your wrapping problem — /copy should give you the raw
  markdown text without the hard-wrapped newlines that the terminal renderer inserts. So
  it may already be the solution you need.

After

---

`/copy` was added in **Claude Code v2.1.59** (February 26, 2026). It copies the last assistant response to your clipboard — and if the response contains code blocks, it opens a picker to choose which block (or the full response) to copy.

That's actually relevant to your wrapping problem — `/copy` should give you the raw markdown text **without** the hard-wrapped newlines that the terminal renderer inserts. So it may already be the solution you need.

</p>
</details>

Full Solutions

---

I still think this is annoying, because you can't copy multiple responses and format them correctly; I end up having to have the agent output it into pbcopy which is a waste of tokens (repeating the request), but it's an improved experience.

1. Would be nice to add something to config to turn off the ⏺ and 2-sp indent
2. Could at least create ctrl+c keypress action that strips ⏺ characters, extra spaces, and the claude-code special linebreaks, piping to pbcopy

Workaround: "Clean Paste" script

Until this is configurable, here's a workaround script that would work with any keyboard-binding program or solution. I used Raycast's script commands since it was free to download. The script cleans Claude Code formatting from the clipboard on paste. Bind it to a hotkey (e.g., Cmd+Ctrl+V) and use it instead of regular paste, so that you can copy multiple claude code output blocks and have all the wrapping and indentation stripped.

Also works as a standalone clipboard cleaner without Raycast, could make an cc or something along those lines to cleanup the last copied clipboard record — just remove the Raycast metadata comments and the final osascript line, then run it after you copy something.

# @ ~/.zshrc
# ...
# Cleans last clipboard item
cclip() {
    pbpaste | perl -0777 -pe 's/^⏺ //mg; s/([^.!?:)\n])\n[ \t]+/$1 /g; s/^[ \t]+//mg' | pbcopy
}

What it fixes

• Strips the ⏺ bullet prefix
• Rejoins soft-wrapped lines (the hard \n inserted at terminal width)
• Strips the 2-space indent on all output lines
• Preserves intentional line breaks (blank lines, sentence boundaries, list items)

[!NOTE] The key regex is s/([^.!?:)\n])\n[ \t]+/$1 /g — it joins a line with the next one when: - The current line does not end with sentence-ending punctuation (.!?:)) - The next line starts with whitespace (Claude Code's indent) This means paragraph breaks, list items (A), B), -, *), and sentence boundaries are

preserved, while mid-sentence word wraps get rejoined.

Raycast Instructions

<details><summary>Expand</summary>
<p>

Regex Script

1. mkdir -p ~/shortcuts/scripts/
2. open ~/shortcuts/scripts/clean-paste.sh and copy the below in.

#!/bin/bash

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

# Documentation:
# @raycast.description Paste clipboard with Claude Code formatting stripped

pbpaste | \
  perl -0777 -pe '
    s/^⏺ //mg;
    s/([^.!?:)\n])\n[ \t]+/$1 /g;
    s/^[ \t]+//mg;
  ' | \
  pbcopy

osascript -e 'tell application "System Events" to keystroke "v" using command down'

1. Save the file.
2. chmod +x ~/shortcuts/scripts/clean-paste.sh

Keyboard Shortcut

1. In Raycast:

| Settings > Extensions > Scripts | Add Script Directory<br>~/shortcuts/scripts | Clean Paste should auto-populate |
|--------|--------|-------|
| <img width="200" height="238" alt="Image" src="https://github.com/user-attachments/assets/0509a4b1-aa23-4027-9948-85fbd7b98a10" /> | <img width="200" alt="Image" src="https://github.com/user-attachments/assets/de3116e2-663e-4778-81d8-02fce4b421b7" /> | <img width="500" alt="Image" src="https://github.com/user-attachments/assets/c660b3e0-1bc1-479e-93dc-1d9b38f26af5" /> |

1. Grant Raycast Accessibility permission in System Settings if needed

</p>
</details>

Examples

<details><summary>Expand</summary>
<p>

_using raw text because the line breaks are getting automatically filtered out in the codeblock, so does not show the issue effectively._

Before (raw Cmd+V from iTerm copy):

---
⏺ You can change it in Raycast Settings → Extensions → Scripts → click the hotkey field for Clean Copy → press Shift+Ctrl+A. That's a
Raycast UI setting, not something in the script file.

❯ We can't pass the selected text in like a param or anything?

⏺ Web Search("Raycast script command receive selected text input clipboard argument")
⎿  Did 1 search in 6s

⏺ Raycast has Pipe Commands — they receive selected text via stdin and output replaces the clipboard. But that requires the Pipe Commands
extension, and pipe commands can't have hotkeys.

For script commands, Raycast can pass clipboard content as stdin with @raycast.currentDirectoryPath ... actually the simpler approach:
since Raycast script commands can read the clipboard directly, and the issue is just that the hotkey triggers before you've copied — what
if we skip the osascript entirely and just use @raycast.input source?

Let me check the exact metadata:

---

After (Clean Paste):
---
You can change it in Raycast Settings → Extensions → Scripts → click the hotkey field for Clean Copy → press Shift+Ctrl+A. That's a Raycast UI setting, not something in the script file.

❯ We can't pass the selected text in like a param or anything?

Web Search("Raycast script command receive selected text input clipboard argument")
⎿  Did 1 search in 6s

Raycast has Pipe Commands — they receive selected text via stdin and output replaces the clipboard. But that requires the Pipe Commands extension, and pipe commands can't have hotkeys.

For script commands, Raycast can pass clipboard content as stdin with @raycast.currentDirectoryPath ... actually the simpler approach:
since Raycast script commands can read the clipboard directly, and the issue is just that the hotkey triggers before you've copied — what if we skip the osascript entirely and just use @raycast.input source?

Let me check the exact metadata:

---

</p>
</details>

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

this is indeed super irritating, why would they add such a stupid "feature"?

I faced same issue and I had to revert from 2.1.87 (ironically latest stable version) to claude 2.1.58 (previous stable).
Other annoying thing is Claude Code github repo hides the Release and Tags Link to download the binaries.
https://github.com/anthropics/claude-code/releases
https://github.com/anthropics/claude-code/tags

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

i can't believe how long such a simple and stupid bug has been sitting here. literally ask claude to fix it and it will be gone in like 20 seconds.

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.

Nine months on and the entire thread is people building external clipboard-scrubbers (Raycast scripts, perl one-liners, cclip) to undo formatting the renderer never should have baked into the buffer. That's the tell: the workarounds exist because the TUI is fighting the terminal's own selection, and every one of them is a per-user, per-OS band-aid for something that should be a single setting.

/copy isn't the fix either. It only grabs the last assistant turn, it can't span multiple responses, and it does nothing for the far more common case — dragging a normal terminal selection across part of a code block. The 2-space indent and hard-wrap-at-80 corrupt that selection every time, and no amount of /copy helps because you're not always copying a whole response.

The core problem is that presentation is being written into the copyable text. The indent and the hard newlines are display chrome; they belong in the render layer, not in what my terminal hands to the clipboard. Please give us a config key to turn it off — disableOutputIndent / soft-wrap instead of hard-wrap, whatever the shape. Even just not injecting the leading 2 spaces and ⏺ into selectable output would fix 90% of the pain without touching the visual layout.

This is a papercut that draws blood a dozen times a day. It's not cosmetic — it silently corrupts pasted shell commands, which is a correctness bug for anyone who copies commands out to run them elsewhere.

Adding measured frequency data, since this thread is long on anecdote and short on numbers. Claude Code 2.1.221, Linux, ~80-col terminal.

How often it actually bites. I scanned my full local transcript history — 509 sessions, 6,729 assistant text messages — counting fenced code-block lines that exceed the usable width (terminal columns minus the 2-space margin):

| | count |
|---|---|
| assistant text messages | 6,729 |
| containing a >78-char code-block line | 91 (1.4%) |

So roughly one message in seventy ships a command that will be corrupted on copy. That is not an edge case, and it is invisible to the model producing it.

The two artifacts are not equally harmful, which I think is worth separating in triage:

• The 2-space indent is nearly harmless for shell commands — bash strips leading whitespace before parsing. It does break heredocs (an indented EOF never matches its terminator, so the shell hangs on > until you Ctrl-C) and any paste into a REPL or YAML.
• The hard wrap is fatal, because the newline is real and in the buffer. A 103-char path split into .../scr + atchpad/... and produced two No such file or directory errors. No amount of careful selection recovers it.

The wrap is the one worth prioritizing. As noted upthread, soft-wrapping code block content only — emitting long lines and letting the emulator wrap them visually — fixes it without touching TUI chrome.

Interim mitigation, if it helps anyone here. Rather than scrubbing the clipboard after the fact, this can be caught before the text is ever emitted, with a Stop hook that inspects the outgoing message and refuses to end the turn while a pasteable code block contains an over-long line. The one non-obvious part: the hook's own stdout is a captured pipe, so it can't read the width from its fds — but it is a descendant of the Claude Code process and shares the controlling terminal, so ioctl(TIOCGWINSZ) on /dev/tty returns the true column count, and the limit tracks window resizes. Falling back through own-fds → walking the process tree for an ancestor's terminal → $COLUMNS → 80 covers the rest.

Replayed against the message that originally broke for me, it blocks with the offending line and its length, and the model reroutes to writing a file plus a short runner command. It's a workaround for the same root cause everyone else is working around, just applied before the buffer instead of after the clipboard — but it does mean the fix doesn't depend on the user noticing.

Happy to share the hook if useful. The underlying ask stands: soft wrap for code block content.

Not bulletproof, but here's a tool I built for this very issue: https://pypi.org/project/unwrap-terminal-text/. Works really well for me, anyway