›_ Claude Code Issues
Claude Code Issues / #6827

[BUG] Hard line breaks at ~80 characters in VS Code extension, breaking copy/paste

Open 💬 16 comments Opened Aug 29, 2025 by psarno

Bug Description

Claude Code inserts hard line breaks at ~80 characters server-side in its terminal output, breaking copy/paste workflows. The display behavior is inconsistent - sometimes line breaks are visible in the VS Code panel, sometimes text appears to flow naturally, but the underlying text always contains embedded hard breaks that appear when copied. Affects workflows when copying terminal output for release notes, documentation, or other text content.

Steps to Reproduce

  1. Ask Claude Code to generate any long text in VS Code
  2. Observe inconsistent display behavior - breaks may or may not be visible in the panel
  3. Copy/paste the text - hard breaks are always embedded at ~80 characters regardless of display

Expected Behavior

Text should flow naturally without embedded line breaks, with consistent display behavior.

Actual Behavior

Hard line breaks inserted every ~80 characters in the underlying text. Display is inconsistent - sometimes shows breaks visually, sometimes appears to flow naturally, but copy/paste always reveals embedded breaks.

Note: The embedded line breaks cause workflow disruption when generating release notes and documentation in GitHub, requiring manual cleanup with DEL key to remove unwanted breaks and whitespace.

Environment

  • Platform: Windows 11
  • VS Code Extension: Claude Code v1.0.96
  • Related Feedback ID: bf385482-e844-4ce9-8830-3649db40e078

Evidence - Claude Code Acknowledges the Issue

When asked about this behavior, Claude Code itself confirmed:

"That's exactly right - and I can see it happening in my responses too. When I try to write naturally flowing text, something on the server side is inserting hard line breaks at around 80 characters, which breaks copy-paste functionality for things like markdown files or release notes. This seems like a bug or overly aggressive formatting rule in Claude Code that should definitely be configurable or removed entirely."

Note: The line breaks are inconsistently preserved depending on the target application. GitHub's markdown editor normalizes them, but they appear in plain text editors and break workflows when generating files.

CRITICAL: Breaking words mid-character

Unwanted breaks - it splits words in the middle (e.g., "useful" becomes "usefu" + "l"), which corrupts the actual content .

<img width="870" height="217" alt="Image" src="https://github.com/user-attachments/assets/bf621cb0-2d72-444d-8dd2-d3a20812d478" />

View original on GitHub ↗

16 Comments

gabrielbryk · 8 months ago

+1 breaks URLs too

speir-wang · 8 months ago

I am on macOS and it's happening on macOS too.

github-actions[bot] · 7 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

bsdis · 6 months ago

+1 im on macos and have same issue.

pentafive · 6 months ago

Confirming this issue on WSL2/Windows 11 with Claude Code 2.0.x.

I've filed #15199 to consolidate this problem with the related indent issue and frame the full scope:

  • Token cost: Prompt-based workarounds in CLAUDE.md waste tokens every session
  • Adoption context: 115k developers using Claude Code, 300% growth - new users won't know workarounds
  • Parity gap: Desktop/Web has copy buttons; CLI bakes artifacts into everything
  • Community evidence: #859 (37+ upvotes), #13378, #5097, #4686

With creators like NetworkChuck driving adoption, first impressions matter. This affects every CLI user's workflow.

Please consider removing the autoclose label.

jsheremeta-alt · 6 months ago

Bug Report: Terminal Output Not Wrapping - Text Cut Off at Screen Edge

Description
Text in Claude Code CLI gets cut off at the terminal edge instead of wrapping to the next line. Long responses are truncated and unreadable.

Environment

  • Platform: macOS 25.2.0 (Darwin Kernel Version 25.2.0)
  • Architecture: ARM64 (T8132)
  • Claude Code Version: 2.1.4
  • Terminals Tested: Warp, macOS Terminal.app
  • Shell: zsh
  • TERM: xterm-256color

Steps to Reproduce

  1. Open any terminal (Warp or Terminal.app)
  2. Run claude and ask any question that generates a long response
  3. Observe text gets cut off at ~80-100 characters instead of wrapping

Expected Behavior
Text should wrap naturally at terminal edge, like any standard Unix command (echo, cat, etc.)

Actual Behavior
Text is truncated at screen edge. Long responses are unreadable.

What I've Already Tried

  • ✅ export COLUMNS=80 - no effect
  • ✅ Multiple terminals (Warp, Terminal.app) - same issue
  • ✅ Standard echo commands wrap fine - this is Claude-specific
  • ✅ Checked for hidden characters with cat -v - clean output

Impact

  • Makes long responses completely unreadable
  • Affects daily workflow - need to constantly scroll sideways or miss content
  • CLI is essentially unusable for anything beyond short responses

This is different from #7670 because that issue is about hard breaks in copied text - this is about text not wrapping at all in live terminal output.

stevegoulet · 4 months ago

+1 - this is a huge problem for me in a regulated environment where I cannot let CC run bash commands directly. MacOS VS Code.

alexbevi · 4 months ago

Same here. Using it from Warp and copy/pasting requires manual reformatting

chosenperson · 4 months ago

The issue still exists, this will cause URL parsing to fail

adereis · 3 months ago

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

astutejoe · 3 months ago

This drives me fucking insane

garrettatx · 3 months ago

Still happening on 2.1.85, macOS, Apple Terminal. Hard line breaks at ~80 chars make it impossible to copy text from terminal output into emails or web forms without manually removing carriage returns. A workaround is writing to a file first, but that defeats the purpose of inline output.

exodar · 3 months ago

Same issue on v2.1.107, MacOS, Visual Studio Code terminal, Apple Terminal, and Termius.

es617 · 2 months ago

Built a workaround for this while waiting for a fix; a shortcut that rewrites the clipboard on a hotkey, joining hard-wrapped lines. https://github.com/es617/clip-unwrap"

lastobelus · 2 months ago

This issue is no longer relevant for me; I just switched to exclusively using t3code.

kyrylo-kochubyey · 1 month ago

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.