[BUG] Text styling (bold, colors) getting progressively misaligned in multi-line responses. It is not fixed in Claude Code 2.1.6

same here, i back to 2.1.2
OS：windows 11 , 200% DPI, use cmd.exe with claude code

Looks like I'm seeing the same thing on Windows, MINGW64 (Git Bash) in Terminal, Claude Code v2.1.12

<img width="1077" height="296" alt="Image" src="https://github.com/user-attachments/assets/8af27d63-b678-4790-b498-df438d6c4c6c" />

Please fix this, it's very annoying. Still happens in 2.1.19.

Additional evidence: Extreme rainbow gradient case

Adding another example of this bug in its most severe form - entire text blocks rendering with rainbow gradient coloring where individual characters cycle through red → yellow → green → cyan → blue.

This occurred on v2.1.19 on Windows (PowerShell 7, Windows Terminal).

Screenshot:
<img width="1130" height="864" alt="Image" src="https://github.com/user-attachments/assets/1fcd7dba-8b80-4e67-8c63-c9dbf24b45ec" />

The bug appears to be getting worse, not better. This is the same underlying ANSI escape code misalignment issue.

<img width="561" height="222" alt="Image" src="https://github.com/user-attachments/assets/5fcec20d-46d4-4ede-bc1c-2a7bf8b7713d" />

This is Delphi code with Syntax highlighting. Doesn't work at all. Claude Code 2.1.29

Root Cause Found & One-Line Fix

Full analysis posted at https://github.com/anthropics/claude-code/issues/14720#issuecomment-3857905322

TL;DR: The bug is in the IP5 function in cli.js. When word-wrapping consumes spaces at line breaks, the style-position tracker $ falls behind by 1 per wrap. This accumulates, shifting all ANSI highlighting rightward over long paragraphs.

The fix: search cli.js for z&&_.length>0 (exactly one match, in the IP5 function). Remove the z&&:

// Before (whitespace correction only runs in trim mode):
if(z&&_.length>0){let W=/\s/.test(_[0]);if($<Y.length&&/\s/.test(Y[$])&&!W)while($<Y.length&&/\s/.test(Y[$]))$++}

// After (whitespace correction runs in all wrap modes):
if(_.length>0){let W=/\s/.test(_[0]);if($<Y.length&&/\s/.test(Y[$])&&!W)while($<Y.length&&/\s/.test(Y[$]))$++}

Tested on 2.1.33, completely eliminates the prose highlighting drift. Code blocks are unaffected (they use a different rendering path). If you ask Claude Code to fix itself using this information, it can locate and patch the function automatically.

Still present on v2.1.34 (latest) + Opus 4.6

Environment:

• Claude Code: v2.1.34
• Model: Opus 4.6 (claude-opus-4-6)
• OS: Windows 11 x64
• Terminal: Windows Terminal
• Shell: PowerShell 7

Reproduction: Any response with mixed formatting (inline code, bold, code blocks, tables) exhibits the misalignment. The longer the response, the worse it gets.

The ANSI escape codes are clearly shifted - colors land on wrong characters mid-word (e.g. fetchUserData splits coloring mid-identifier, WARNING in bash block has colors scattered across random chars). Tables, bullet lists with inline code, and longer code blocks all affected.

This has been broken since v2.1.3 (4+ weeks now) and affects every Windows user. It makes code review in Claude Code essentially unusable since you can't trust the highlighting. This should be high priority given Claude Code is primarily a coding tool.

Previously reported as #20827 (closed as dup of this issue).

<img width="1831" height="1301" alt="Image" src="https://github.com/user-attachments/assets/e879e02d-4678-4d74-9754-da64db6db83f" />

@km-anthropic Hey Kashyap, any chance you could help escalate this issue? It's been an ongoing issue for all Claude Code users on Windows for over a month. Thank you for any help 🙏

The good news is that it's easily reproducible and there has been some helpful sleuthing in this thread.

I am begging you fix this. I am stuck at 2.1.1 where this bug does not appear. I really want to upgrade, but this offset is driving my crazy....

I have lost 3 hours trying to fix this. Please work on it...
Also:
Windows 11
Powershell 7
CC ver: 2.1.38

The problem is that they do strip Windows-specific \r when wrapping long lines, but do not when calculating where to put styling.
Plus an additional error when they do a "sanity check" and compare the end of line to be in fact \n, but there is \r instead on Windows, so they end up with +2 chars styling offset for every line (instead of 1 if there was only one bug).

For anyone terminally desperate, here's a gist. It's an old-school runtime patcher to fix the vibe-coded slop. At least I restored my sanity, at least in Windows 10 - Windows Terminal - PowerShell - GitBash: markdown formatting is properly aligned once again. But you need to be really desperate to use it, as runtime in-memory patcher is an overkill and universally dangerous.

Original (as of 2.1.39)
<img width="974" height="828" alt="Image" src="https://github.com/user-attachments/assets/622d0f5b-6570-4075-bc29-b93b759dc095" />

With patch
<img width="974" height="828" alt="Image" src="https://github.com/user-attachments/assets/f90d5ec0-5799-4a22-acc6-277246812e7d" />

Happens on Windows 10 terminal. I don't use an IDE so this is a truly readability-crippling bug. Others have already voiced their complaints, just adding here in the hopes Anthropic Team notices.

Currently using @frostbtn's workaround til then

Same issue...

<img width="732" height="567" alt="Image" src="https://github.com/user-attachments/assets/d3f09087-ab4f-441d-9e6f-5dbeda712247" />

In case we'll manage to lure Claude the slopbot here, here's a reproduceable scenario.

Windows 10/11.
True-native installation, i.e. installation on Windows host directly, not into WSL2 that is a virtual machine with Linux.
GitBash.
Windows Terminal, CMD, or ConEmu.
2.1.41 is definitely affected. As per @countzero analysis, last know error-free version is 2.1.12 and first broken is 2.1.14.

With the prompt.md.

When the console in wide enough to accommodate all message lines, there's no drift in formatting, no problems:
<img width="525" height="445" alt="Image" src="https://github.com/user-attachments/assets/db0310ba-ddcc-4b32-bef0-1063288b4c97" />

When _any_ line _anywhere_ in the message needs wrapping, the whole styling on that message gets drifted +2 chars per lines
<img width="525" height="445" alt="Image" src="https://github.com/user-attachments/assets/7ee3d7c0-3682-440c-b496-7ad8a5b25685" />

Problematic code logic being:

• In rendering-out messages loop.
• Raw message content gets read from the DOM nodes they have \r\n line-endings on Windows.
• Then in this _raw_ string (with \r\n) styles are mapped to character offsets.
• Then this _raw_ strings is sent for wrapping. And the wrapping function "normalize" the string with ".normalize().replaceAll(\\r\n,\n)" code, removing \r-s from the string. Style map doesn't get updated and contains offsets from the original _raw_ string.

There's also another error that is harder to pin-point exactly, leading to an additional char to styling offset per line. Instead of being off by +1--as is expected if only one \r per line gets removed--the actual offset is +2 per line. Allegedly, there's a line checking the line ends with \n, and if not (and it is not as there is \r instead), offsets to the nearest \n, adding +1. This is done after wrapping. It's hard to figure out from minified code, why it's being done other for "sanity check".

And the root cause is this ancient cargo cult of "Windows needs special treatment for line endings!!1" shared by non-users. Windows does not--for decades, and handle \r\n, \n, and \n\r perfectly well as-is. Literally, disabling this replacement in-memory in Claude Code solves the problem. Or, if following that cargo cult is bot's personal religion, at least "normalize" line endings directly after getting strings from the DOM nodes. Anyway, both styling and wrapping should work with the same string, not differently cooked.

I'm running CC v2.1.47 and it looks like I'm not seeing the syntax highlighting drift anymore 🙏

<img width="1089" height="1091" alt="Image" src="https://github.com/user-attachments/assets/56f76e02-0eb9-47b4-b9ab-52ffef1cb974" />

today 2.1.47 fixed this

I'm still getting formatting drift in CC 2.1.50. - possibly unrelated solution to similar problems, as it appears only some time after working in the same context - I created issue #26111

This was fixed in v2.1.47 — Bold/color styling no longer drifts progressively out of alignment across multi-line responses on Windows. If you're still seeing this in the latest version, please comment with your version and repro and we'll reopen.

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.