Text rendering bug in version 2.0.73 on Windows

Same here. Not just malformed, but whole sections of the output are missing and not rendered, but there is black space with no content where there should be content.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/14594
2. https://github.com/anthropics/claude-code/issues/14678
3. https://github.com/anthropics/claude-code/issues/14694

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

Additional Investigation

After further investigation, we can confirm:

Root Cause

• This is NOT an encoding issue - changing console encoding (UTF-8, chcp 65001, PowerShell OutputEncoding) does not fix the problem
• The bug appears to be in the internal text renderer of Claude Code 2.0.73
• Text is being fragmented during UI rendering, not during output

What We Checked

• .claude.json configuration - no encoding settings available
• .claude/settings.json - no encoding settings available
• PowerShell UTF-8 encoding settings - no effect
• Windows Terminal vs cmd.exe - same issue on both

Confirmed Fix

• Downgrade to 2.0.72 completely resolves the issue

``
npm install -g @anthropic-ai/claude-code@2.0.72
``

Possible Cause

Looking at the 2.0.73 changelog:

Added clickable [Image #N] links that open attached images in the default viewer

This change to text rendering may have introduced the bug.

Environment

• Windows 10/11
• Node.js (via nvm)
• Affects both cmd.exe and Windows Terminal
• Affects both PowerShell and bash (Git Bash/MSYS)

it's full of these reports already, but just downgrade to previous version

Source Code Analysis

I analyzed the differences between cli.js in v2.0.72 and v2.0.73 (~20KB difference).

New Code in 2.0.73 for Clickable Images

Parser function QQ7 - Splits text when it finds [Image #N] pattern:

function QQ7(A) {
  let Q = /\[Image #(\d+)\]/g, B = [], G = 0, Z;
  while ((Z = Q.exec(A)) !== null) {
    if (Z.index > G) B.push({type: "text", content: A.slice(G, Z.index)});
    B.push({type: "image", content: Z[0], imageId: parseInt(Z[1] || "0", 10)});
    G = Z.index + Z[0].length;
  }
  // ... rest handles remaining text
  return B;
}

Renderer function okA - Renders mixed text/image segments:

function okA({text: A, backgroundColor: Q, color: B}) {
  let G = QQ7(A);
  if (G.length === 1 && G[0]?.type === "text") 
    return createElement(C, {color: B}, A);
  return createElement(Fragment, null, G.map((Z, Y) => {
    if (Z.type === "image") 
      return createElement(akA, {imageId: Z.imageId, ...});
    return createElement(C, {color: B}, Z.content);
  }));
}

Link component akA - Creates clickable ink-link:

function akA({imageId: A, ...}) {
  // Uses ink-link for clickable images
  if (Lv()) // Lv() checks if terminal supports links
    return createElement(Q9, {url: Y}, createElement(C, {underline: true}, Z));
  return createElement(C, {}, Z);
}

Likely Root Cause

The Lv() function checks terminal link support:

function Lv() {
  if (NVB.default.stdout) return true;  // Always true if stdout exists!
  // ... other checks for TERM_PROGRAM
}

Problem: On Windows, Lv() returns true (because stdout exists), but the ink-link element doesn't render correctly in Windows terminals, causing the text fragmentation/corruption.

Suggested Fix

Either:

1. Fix Lv() to properly detect Windows terminal capabilities
2. Or disable clickable images on Windows until properly supported

Root Cause Analysis

I've done a detailed analysis comparing the minified code between 2.0.72 (working) and 2.0.73 (buggy) and found the root cause.

What Changed in 2.0.73

Version 2.0.73 introduced clickable \ links using OSC 8 hyperlink escape sequences. The key new functions are:

• \ - Creates clickable image component using \ link wrapper
• \ - Wraps text with OSC 8 escape sequences: - \ - Renders text with image segments, creating hyperlinks for image references

The Bug

The ANSI stripping regex in \ does not properly match OSC 8 hyperlink sequences.

Test showing the issue:
\
This causes:

1. Width calculations include the invisible escape sequence characters
2. Word-wrapping breaks because text appears wider than it is
3. Layout becomes fragmented with large empty spaces

Proposed Fix

Add an OSC 8 specific pattern to the ANSI regex:

\
Alternative quick fix - explicitly disable hyperlinks on Windows in \:
\

Files Involved

The relevant functions in cli.js (minified names may vary):

• \ - ANSI regex generator (strip-ansi package)
• \ - Uses zl1 regex to strip ANSI codes
• \ - String width calculation, calls PX
• \ - Creates OSC 8 sequences
• \ - Checks terminal hyperlink support

Root Cause Analysis

I've done a detailed analysis comparing the minified code between 2.0.72 (working) and 2.0.73 (buggy) and found the root cause.

What Changed in 2.0.73

Version 2.0.73 introduced clickable [Image #N] links using OSC 8 hyperlink escape sequences. The key new code:

• A new function that creates clickable image components using link wrappers
• A function that wraps text with OSC 8 escape sequences: ESC]8;;URL BEL TEXT ESC]8;; BEL
• Updated text rendering to create hyperlinks for image references

The Bug

The ANSI stripping regex does not properly match OSC 8 hyperlink sequences.

When text contains OSC 8 hyperlinks, the width calculation includes the escape sequence characters (which should be invisible). This causes:

1. Text appears wider to the layout engine than it actually is
2. Word-wrapping breaks incorrectly
3. Layout becomes fragmented with large empty spaces

Example: A string like [Image #1] (11 chars visible) with OSC 8 wrapping is actually 38+ chars. The layout engine allocates space for 38 chars but only 11 are visible, creating gaps.

Proposed Fixes

Option 1 (Recommended): Add OSC 8 pattern to the ANSI stripping regex used by the strip-ansi package:

\x1B\]8;;[^\x07]*\x07

Option 2 (Quick fix): Explicitly disable hyperlinks on Windows in the terminal link support check:

// In the link support check function, add at the beginning:
if (process.platform === 'win32') return false;

This prevents OSC 8 sequences from being generated on Windows where they cause issues.

Files Involved (in minified cli.js)

• ANSI regex generator function (from strip-ansi package)
• String width calculation function that calls the regex
• OSC 8 sequence generator function
• Terminal hyperlink support check function

Verification

I confirmed the regex issue with this test:

• Original text with OSC 8: 38 characters
• After stripping with current regex: 38 characters (NOT stripped!)
• Expected after stripping: 11 characters (just the visible text)

It is a duplicate of #14554

I'm having the same issue, so far using just regular windows command prompt instead of terminal is working for me (cmd.exe)

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.