[BUG] Random colored text fragments in terminal output

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/2780
2. https://github.com/anthropics/claude-code/issues/14720
3. https://github.com/anthropics/claude-code/issues/17050

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

Same here in 2.1.5 Opus on Windows 11 via standard Command Prompt.

<img width="1115" height="894" alt="Image" src="https://github.com/user-attachments/assets/01e3b7a8-c6a1-461c-840c-4d8a476d6612" />

me too.

I reported https://github.com/anthropics/claude-code/issues/20459 but I closed it because this one is older. I linked mine though so you can see details about my computer and versions.

also here is my screen shot

<img width="1887" height="1121" alt="Image" src="https://github.com/user-attachments/assets/2ef6777f-0da0-4439-853e-64ffca97f90a" />

and another:

<img width="1276" height="430" alt="Image" src="https://github.com/user-attachments/assets/4b91b74f-29aa-4f0d-a05d-25ed8d412fdf" />

Same on v2.1.23
I am using the native installer on Windows. Not the node based installer.
I have a coworker that still uses WSL who does not see this behavior.

This is how it looks in my Windows Terminal. Very annoying.

<img width="1412" height="869" alt="Image" src="https://github.com/user-attachments/assets/54e6edc3-331e-4bf1-a664-2b5439f17d15" />

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.

I am seeing the incorrect coloring on my Claude (started happening within the last two weeks) and so is a coworker that just installed claude fresh.

@WargameGPT bless you for that advice! It works brilliantly! I went a bit further and wired the patching to SessionStart Hook to check for Claude updates and implement the patching to the new version automatically. Here's the summary of what we did with Claude for Windows. Hope it might be helpful for others.

Fix: ANSI Highlight Drift (Random Color Fragments in Terminal Output)

Symptoms: Random colored text fragments appear in normal Claude responses. Colors shift rightward after line breaks, getting worse with longer outputs. Not error messages — just broken ANSI highlight re-application after word-wrap.

Root cause: The bundled Bun binary has a function bh0 (in Ink's rendering pipeline) with TWO re-sync blocks gated by parameter D (default false). Both blocks are dead code, causing the style-map index to drift after word-wrap line breaks.

Fix approach: Patch X&& (3 bytes) to (3 spaces) in both gate conditions. Each pattern appears twice (Bun double-embed = 4 total patches). Auto-update overwrites the fix, so a SessionStart hook re-patches automatically.

The Two Patterns

Pattern 1 (start-of-line): if(D&&_.length>0){let F=/\s/.test(_[0])

• Anchor: .length>0){let with 4 pre-bytes matching X&&Y
• Skips whitespace in original text when wrapped line starts with non-space

Pattern 2 (end-of-line): if(D&&M<I.length-1){let F=I[M+1]

• Anchor: .length-1){let with 6 pre-bytes matching X&&Y<Z
• Peeks at next line's first char, skips whitespace until finding it

Implementation

Solved with ~/.claude/hooks/modules/binary-patcher.js (JS SessionStart hook). The patcher:

1. Finds latest version file by semver in ~/.local/share/claude/versions/
2. Reads binary into Buffer, searches for both pattern anchors
3. Replaces X&& (3 bytes) with spaces in each match
4. Writes patched buffer to version file
5. Attempts to copy to claude.exe (rename strategy). If locked (common — current session holds it), spawns a detached background watcher that polls every 5s until the exe is released, then copies automatically
6. Caches mtime/size in state file (exePending flag tracks incomplete exe patches, confirmNext flag triggers success message on next session)

User-facing messages

Messages flow via SessionStart additionalContext → Claude relays in first response.

| Scenario | Message |
|----------|---------|
| Fresh patch, exe copied | "Restart Claude Code for the fix to take effect." |
| Fresh patch, exe locked | "Close all sessions. Background process will update." |
| Next session after watcher | "Fix applied successfully. Colors should render correctly." |
| Exe pending retry success | "Fix applied successfully." |
| Exe pending retry failed | "Fix is queued. Background process will update." |

I actually like this. It's kind of like Bionic reading.

Same issue, although @WargameGPT fix didn't work for me as I didn't use NMP to install and I can't seem to find my cli.js file for Claude?

Regarding to https://gist.github.com/frostbtn/f85b574ce132c8853945df852e1e0d31 the bug was introduced with Claude Code 2.1.14 that implies that version 2.1.12 from ~ a month ago is the last officially usable version for Windows.

Workaround

claude install 2.1.12

@bcherny, @ashwin-ant and @fvolcic please take a look at this coloring bug, it renders the app unusable on Windows and there is now a sufficient amount of tickets regarding this issue with deep analysis and sound solution suggestions.

This hook worked for me. I am using CC native ARM64 binary. I know the pattern is the same in the other architectures' binaries, but I don't know if there are any differences to take into account. You could start with these and ask Claude to check them and implement them according to your current installation.

OneDrive Folder with Hook

If anyone can get the attention of anthropic devs to implement a fix of the root cause (as identified by @WargameGPT - https://github.com/anthropics/claude-code/issues/17314#issuecomment-3857915285) that would be super.

If you installed CC via irm https://claude.ai/install.ps1 | iex (because the docs say installation via npm is deprecated), cli.js does not exist so we can't use the fix above. I tried to revert to 2.1.14, but the problem persisted there. In case my methodology was flawed, here's where I found the old version:

https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/2.1.14/win32-x64/claude.exe

(You're probably not willing to download an exe from a random https://storage.googleapis.com URL, so take a look at the contents of https://claude.ai/install.ps1 and observe that this is the URL they're using.)

I put this where I installed the old version, $HOME\.local\bin\claude.exe, ran claude, and still see the error, even though the version is clearly 2.1.14.

<img width="1586" height="602" alt="Image" src="https://github.com/user-attachments/assets/e5aafc37-d4c3-4c77-96b9-9da83460456d" />

If you installed CC via irm https://claude.ai/install.ps1 | iex (because the docs say installation via npm is deprecated), cli.js does not exist so we can't use the fix above.

I am not using the npm version of CC. Mine is Windows native install using irm https://claude.ai/install.ps1 | iex.

The fix that I referenced (hook) works. There is no cli.js file as an independent file; it is packaged within the claude.exe binary. The hook patches the binary file that is downloaded to {userprofile}\.local\share\claude\versions and then overwrites the claude.exe in {userprofile}\.local\bin (the actual claude code binary) when the file is no longer in use.

## Root Cause Found & One-Line Fix Full analysis posted at #14720 (comment) 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.

It sure would be nice to get Anthropic to take care of this. We have internal users starting to complain the output is hard to read. This seems like a silly simple fix to implement, test and release.

It's a quality-of-life issue for many, especially those with visual impairments.

Fixed in 2.1.47

<img width="731" height="166" alt="Image" src="https://github.com/user-attachments/assets/23745f19-5df7-4075-9b34-fe0151e5cacf" />

Still not fixed for me on claude --version - 2.1.47 (Claude Code)

Fixed in 2.1.47

I hope this is true. Unfortunately, 2.1.47 breaks Bun on ARM64 Windows, so I'm stuck on 2.1.45 until that regression is fixed.

seems it's fixed for me in 2.1.50

Fixed for me in 2.1.50. Thank you.

Fixed for me now too. Thank you!

This colored text fragment issue is usually caused by ANSI escape sequence handling differences between terminals on Windows.
Workaround 1 — Set TERM environment variable:

$env:TERM = "xterm-256color"
claude

Or in your PowerShell profile ($PROFILE):

$env:TERM = "xterm-256color"

This tells Claude Code to use standard xterm color codes instead of potentially unsupported sequences.
Workaround 2 — Enable Virtual Terminal Processing:
In PowerShell:

[console]::OutputEncoding = [System.Text.Encoding]::UTF8
$env:COLORTERM = "truecolor"

Workaround 3 — Use Windows Terminal instead of VS Code terminal:
Windows Terminal generally has better ANSI support than VS Code's integrated terminal on Windows. If you're seeing this in VS Code, try running claude in Windows Terminal directly.
Workaround 4 — Force ANSI theme:

claude --theme ansi-dark  # or ansi-light

The ANSI themes use the basic 16-color palette which is more universally supported than 256-color or truecolor modes.
Workaround 5 — Disable colors entirely:

$env:NO_COLOR = "1"
claude

The NO_COLOR environment variable (from no-color.org) tells CLI tools to disable all color output. This removes the visual artifacts at the cost of a monochrome experience.

This is a duplicate of #17892, which was fixed as of version 2.1.47.

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.