Spinner uses small-caps Unicode codepoints that render as tofu in many fonts

Resolved 💬 3 comments Opened May 14, 2026 by Faithfinder Closed May 14, 2026

Summary

The thinking/working status line in the CLI styles words like "Whisking" and "thinking" by substituting individual letters with their Unicode small-caps codepoints (e.g. gɢ U+0262). Different letters get the treatment over time, so it looks like a deliberate stylistic flourish rather than a typo. The problem: terminals with fonts that don't have glyphs for these codepoints render them as tofu/boxes, so words look broken instead of stylized.

Repro

  1. Run any prompt that triggers extended thinking, so the status spinner is visible.
  2. Watch the spinner text — letters in "Whisking" / "thinking" / etc. cycle through small-caps Unicode variants.
  3. In a terminal font without full small-caps coverage, the affected letters render as .

Observed

  • gɢ (U+0262) confirmed
  • Other letters appear to get similar treatment intermittently (user reports "weird symbols flashing on other letters from time to time"), e.g. ɴ, ʀ, s, etc. — these all live in obscure IPA / phonetic Unicode blocks that most monospace fonts skip.

Example rendering with a font lacking U+0262:

* Whiskin▯. (7m 22s · ↓ 25.2k tokens · almost done thinkin▯)

Expected

The stylistic intent should survive on common terminal fonts. Today it doesn't.

Suggested fix

A few options, roughly in order of cheapest first:

  1. Feature-detect glyph coverage and fall back to plain ASCII letters when the active font can't render the small-caps codepoints (hard to do reliably in a terminal, but possible via probe-and-measure).
  2. Restrict the substitution set to small-caps codepoints with broad font coverage (ʙ, , , etc. from U+1D00 block are slightly better-covered than ɢ/ɴ/ʀ, but still spotty).
  3. Drop the Unicode small-caps trick and use a different visual flourish that doesn't depend on font coverage — e.g. dim/bold ANSI styling, color cycling, or a CSS-style true small-caps effect isn't available in terminals, so this likely means a different effect entirely.

The current behavior is a cute easter egg but it actively makes the UI look broken on a meaningful slice of terminal setups (including VS Code's integrated terminal with default settings).

Environment

  • Claude Code: 2.1.141
  • Terminal: VS Code integrated terminal 1.119.0 (xterm-256color)
  • OS: macOS (Darwin 25.5.0)

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗