Spinner characters have inconsistent widths in Noto Sans Mono

Fix: override spinner frames with uniform-width characters

// ~/.claude/settings.json
{
  "spinnerFrames": ["⠋", "⠙", "⠹", "⠸", "⠼", "⠴", "⠦", "⠧", "⠇", "⠏"]
}

Braille characters (U+2800 block) are consistently single-width across virtually all monospace fonts, including Noto Sans Mono.

{
  "spinnerFrames": ["-", "\\", "|", "/"]
}

These are guaranteed to be exactly one character wide in any monospace font.

It would be nice if that worked! It does not work. (It doesn't seem that spinnerFrames is a config value, or it doesn't change the behavior of claude.)

I need to correct my earlier suggestion — spinnerFrames is not a valid settings.json key. I checked the source code (v2.1.87) and it doesn't exist anywhere.
The spinner-related settings that actually work in settings.json are:

• spinnerVerbs — customize the verb text shown during spinner

``json
{ "spinnerVerbs": { "mode": "replace", "verbs": ["Thinking", "Processing"] } }
``

• spinnerTipsEnabled — show/hide tips during spinner (true/false)
• spinnerTipsOverride — customize tip text

Unfortunately, the animation frames themselves (the ⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏ characters) are hardcoded and can't be customized through settings. The width inconsistency you're seeing with Noto Sans Mono would need to be fixed either in the font or in the source code.
Sorry for the incorrect information earlier.

I'm experiencing the same issue with spinner rendering causing visual clutter.

The core problem is that there's no way to disable the spinner animation entirely. The spinner is not essential functionality, and users should be able to disable it completely.

What's frustrating is that customization efforts seem focused on non-essential features like spinnerVerbs (whimsical flavor text customization), while basic functionality like "disable spinner animation" remains unavailable.

Please add a proper option to disable the spinner animation entirely.

Adding evidence to this thread. The body spinner (separate from the title bar braille spinner some folks mentioned above) has the same issue on v2.1.143, and the cause is sitting right in the bundled JS:

if (process.env.TERM === "xterm-ghostty")
  return ["\xB7","\u2722","\u2733","\u2736","\u273B","*"];   // · ✢ ✳ ✶ ✻ *
return ["\xB7","\u2722","\u2733","\u2736","\u273B","\u273D"]; // · ✢ ✳ ✶ ✻ ✽

These dingbats have intentionally different ink weights by Unicode design (compare ✳ EIGHT SPOKED ASTERISK with ✶ SIX POINTED BLACK STAR). Even in a true monospace font where every cell has the same advance width, the visible glyph shrinks and grows frame-to-frame. The eye reads that as horizontal jitter.

I tried swapping fonts (IoskeleyMono to Monaspace Neon NF), pinning the codepoints via font-codepoint-map in Ghostty, and disabling the shimmer animation via a custom theme. None help, since the inconsistency is intrinsic to the glyph set, not the font or terminal.

Two clean fixes:

1. Swap the cycle to uniform-weight glyphs. Braille (⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏) works great, or a single character pulsing through dim and bright color.
2. A spinnerFrames or disableSpinner setting in settings.json (plus one to @kyoh86's earlier ask).

Happy to test a fix in a beta.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

I cannot accept that an issue is closed simply because there was "no reaction" while the maintainer completely ignored it. Why can't the maintainer at least show some kind of response? Stop closing issues without responding at all. At the very least, examine the content properly.

We came here to report issues, not to scribble on a restroom wall. We pay a certain cost to report problems and to investigate them.

Getting this on Windows Terminal (WSL2, Ubuntu) with Claude Code 2.1.183 — same horizontal jitter as described. The issue isn't specific to Ghostty or COSMIC Terminal. Claude notes that "it reproduces broadly across terminals wherever the ornament glyphs render with inconsistent advance widths".

Would really like to see this fixed properly.

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.