[BUG] Copied multi-line commands from Claude Code output contain formatting artifacts — still unfixed after 6+ months

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/18798
2. https://github.com/anthropics/claude-code/issues/23014
3. https://github.com/anthropics/claude-code/issues/15199

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 not a duplicate — this is a report about an issue that has been bounced between 6+ closed/locked issues over 6 months with zero developer engagement. The duplicate chain is documented in the issue body.

Regarding the technical fix: a simple approach would be a raw output mode toggle in the terminal. When enabled, Claude Code output renders as plain text without any TUI formatting — no line-number prefixes, no rich wrapping, no invisible characters. Users could toggle it on when they need to copy a command, copy clean text, and toggle it back off.

This would be a minimal, non-breaking feature that solves the problem without requiring a rewrite of the TUI rendering layer. Even a per-block "Copy" button on code blocks (as suggested in the now-closed #35446) would address the most common use case.

Please do not auto-close this as a duplicate. Every prior report of this issue has been closed without resolution.

This is NOT a duplicate of #18798, #23014, or #15199. Those issues describe related but distinct problems:

• #18798 is about line wrapping artifacts in terminal output
• #23014 is about ANSI escape codes leaking into copied text
• #15199 is about markdown rendering stripping code formatting

This issue is specifically about multi-line command blocks that, when copied from Claude Code output, contain invisible formatting characters (zero-width spaces, non-breaking spaces, or similar) that cause the pasted command to fail silently in the terminal. The command looks correct but doesn't execute properly.

A straightforward fix would be a "raw mode" toggle or a copy-to-clipboard button on code blocks that strips all non-ASCII formatting before copying. This is a distinct UX problem from the rendering issues in the linked duplicates.

Please don't auto-close this — it's been reported repeatedly under different symptoms for 6+ months precisely because the root cause hasn't been addressed.

Workaround: Temp File + External Editor

Until this is fixed, here's the workaround we're using in our daily workflow:

1. Have Claude Code write the text to a temp file (/tmp/message.txt)
2. Open it in an external editor (open -a "Sublime Text" /tmp/message.txt)
3. Copy from the editor — clean text, no invisible characters
4. Delete the temp file

This bypasses the TUI rendering layer entirely. Works for any text you need to copy — commands, messages, code blocks, etc.

It's effective but highlights how broken the copy experience is — we shouldn't need to round-trip through the filesystem to get clean text out of a terminal tool.

Another concrete reproducer, different environment (Linux, bash on a TACC HPC login via SSH from Windows).
Claude Code renders fenced code blocks with two leading spaces injected in front of every line inside the
block. The spaces survive copy + paste into the terminal.

For python -c "..." snippets this is a hard failure — Python raises IndentationError on the first non-blank
line:

(env) $ python -c "
> import psycopg2
> conn = psycopg2.connect(...)
> ...
> "
File "<string>", line 2
import psycopg2
IndentationError: unexpected indent

Claude's source output has zero leading indent on those lines; the two spaces are injected at render time, so
the user has no way to work around it via prompting — asking Claude to "please don't indent" doesn't help,
because the model is already outputting flush-left.

Distinct from the earlier ANSI/wrap/markdown reports in this chain: the inserted character is a plain U+0020
space, there's no wrapping involved, and the failure happens even on short blocks that fit in one terminal
line. Any python -c, heredoc, or other indent-sensitive multi-line snippet becomes unrunnable.

Workarounds we've landed on:

• Commit the snippet to the repo as a real .py file, execute via python path/to/file.py.
• Collapse the snippet to a single line with ; separators (ugly but indent-safe).
• The temp-file + external editor workflow from the earlier comment.

A zero-indent-in → zero-indent-out rendering mode (or a per-block "copy raw" affordance) would fix this class
of failure for every indentation-sensitive language, not just the command-line-flag case originally
reported.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Please fix this :)

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.