Spinner glyph U+2733 (✳) renders double-width on Windows, shifting the whole status line every animation frame

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Version: Claude Code 2.1.206 (latest as of filing)
Where Claude Code runs: Windows 11 and Linux HPC (Rocky Linux accessed over SSH)
Where it's displayed: Windows 11 clients — reproduced identically in Windows Terminal, WezTerm, and Alacritty (shell: WSL2 Ubuntu)
Not reproducible on: macOS clients (same Claude Code instance, same SSH connection)

Summary

During the "thinking" spinner, the entire status line (Unfurling… (39s · ↓ 744 tokens · …)) jitters horizontally: on some animation frames all trailing text sits exactly one column further right, then snaps back on the next frame.

The cause is one specific character in the spinner animation cycle. The spinner rotates through several asterisk-like glyphs: ✢ ✳ ✶ ✻ ✽. Four of them render as single-width text. One of them — U+2733 EIGHT SPOKED ASTERISK (✳) — is an emoji-presentation character, and on Windows the font fallback renders it as a double-width color emoji glyph (it even ignores the terminal foreground color, unlike the other spinner frames which follow the theme color). Every frame containing U+2733 pushes the rest of the line one cell right; every other frame pulls it back. At the spinner's frame rate this reads as constant vibration.

Why this is a width-table mismatch, not a rendering glitch

Claude Code computes line layout server-side using its own character width table, which treats U+2733 as 1 cell — consistent with POSIX wcwidth and with the Unicode default for this codepoint. The Windows client renders it as 2 cells. Since Claude Code runs remotely over SSH, no client-side setting can inform it of the disagreement.

Per Unicode character data (codepoints.net/U+2733): U+2733 is designated as emoji but its default presentation is text — monochrome and narrow — unless explicitly followed by U+FE0F. Claude Code emits the bare codepoint, so by spec it should render narrow everywhere. Windows' emoji font fallback substitutes the double-width color glyph anyway; macOS follows the spec default, which is why Mac users never see this.

Everything already ruled out

Client side:

• Three terminal emulators with different rendering architectures: Windows Terminal (AtlasEngine), WezTerm (HarfBuzz shaping), Alacritty (strict cell grid). Identical one-column displacement in all three — not a shaping or renderer-specific bug.
• Windows Terminal "Text measurement mode": both wcswidth and Grapheme clusters tried; no difference.
• Windows Terminal "Full-color Emoji" toggle: Off changes nothing — width allocation happens before the color/monochrome decision; the toggle only affects coloring, not cell count.
• All other Windows Terminal settings: Graphics API (Direct3D/Direct2D), swap-chain invalidation, antialiasing, strict-monospace fonts (JetBrainsMono Nerd Font Mono and others).

Claude Code side:

• CLAUDE_CODE_NO_FLICKER=1: no effect, as expected — this is not a frame-tearing/flicker problem. Every frame renders stably; the content position differs between frames because the width math differs. Please don't dedupe this into the flicker mega-issues; it is a different failure mode with a different fix.
• Version 2.1.206 confirmed up to date, so the spinner-jitter fixes shipped around v2.1.19–v2.1.83 do not cover this case.

Impact

Cosmetic but constant: the status line vibrates during every thinking phase on every Windows client regardless of terminal choice. No client-side workaround exists (exhaustively verified above) short of disabling animations entirely.

Frames extracted from screen recording

Below: two consecutive spinner frames; the red guide line shows the one-column shift of all trailing text.

<img width="1824" height="468" alt="Image" src="https://github.com/user-attachments/assets/e6ffa177-fbf1-4854-b92a-2449eb74a524" />

What Should Happen?

Every frame of the spinner animation should occupy the same number of terminal cells, so the status line stays horizontally stable during the thinking phase — no per-frame one-column shift. The animation itself is great and should stay; the request is only that each frame occupy the same width.

Suggested fix (one-line)

In order of preference:

1. Emit U+2733 with the text presentation selector: send \u2733\uFE0E instead of the bare codepoint. This explicitly requests the narrow monochrome glyph on every platform and matches the width Claude Code already assumes. Zero visual change on macOS/Linux; fixes Windows.
2. Replace U+2733 in the spinner cycle with a glyph that has no emoji presentation (e.g. U+2731 ✱ or U+2735 ✵ — worth verifying their properties).
3. Offer an ASCII spinner option (| / - \) as a fallback for constrained environments.

Option 1 achieves this without changing the design.

Error Messages/Logs

Steps to Reproduce

Minimal reproduction (no Claude Code needed)

On any affected Windows terminal:

for g in '✢' '✳' '✶' '✻' '✽' '*'; do printf '%s|end\n' "$g"; done

Expected: all | characters vertically aligned.
Actual on Windows: the | on the ✳ line is displaced one column to the right; all other lines align. The ✳ also renders as a color emoji glyph rather than a theme-colored text glyph. On macOS the same command produces perfectly aligned output and a monochrome ✳.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.206 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_