[BUG] Windows: statusLine command is spawned with cp1252 stdout — scripts printing non-Latin-1 glyphs crash with UnicodeEncodeError

What happens

On Windows, Claude Code spawns the statusLine command as a subprocess with its stdout connected to a pipe (not a TTY) and without forcing UTF-8 in the child environment. A piped Python process therefore falls back to the locale ANSI codepage (cp1252) for sys.stdout. Any status line that prints a code point outside Latin-1 — box-drawing chars (│, ─), middots (·), arrows (→), check/cross marks (✓/✗), Nerd Font glyphs — crashes the child with:

UnicodeEncodeError: 'charmap' codec can't encode character '\u2502' in position 4: character maps to <undefined>

The status line then renders blank/stale. The same script runs fine when invoked manually, because the interactive terminal stdout is UTF-8 — so it looks like a "works on my machine" config issue when it's actually the spawn environment.

Minimal repro

sl.py:

import sys, json
json.load(sys.stdin)      # consume the status-line JSON payload
print("ctx │ 42%")        # U+2502, a normal box-drawing glyph

settings.json:

{ "statusLine": { "type": "command", "command": "python C:/path/to/sl.py" } }

• Expected: status bar shows ctx │ 42%
• Actual: status bar is blank; child exits with the UnicodeEncodeError above
• Sanity check: echo '{}' | python C:/path/to/sl.py in a UTF-8 terminal prints fine — confirming the divergence is the spawn environment, not the script

Environment

• Claude Code 2.1.179, Windows 11
• Python 3.11.9, system ANSI codepage 1252 (Windows-1252) — i.e. a default en-US/Western install, not an exotic locale

Root cause

The status line child inherits the Windows ANSI codepage for stdout because it's piped and UTF-8 isn't forced. This is the same mechanism as the (closed) skill-creator crash #44563 — a CC-spawned Python subprocess dying on cp1252 stdout.

Suggested fix (any one resolves it)

1. Preferred: set PYTHONUTF8=1 in the environment Claude Code uses to spawn the statusLine command. Tiny blast radius (only the status-line child), fixes all Python status lines transparently.
2. More general: spawn the status-line command with a UTF-8 environment / codepage so non-Python scripts benefit too.
3. At minimum — document it: the statusLine docs should note that on Windows the command is spawned with the ANSI codepage, and scripts emitting non-ASCII must force UTF-8, e.g. sys.stdout.reconfigure(encoding="utf-8", errors="replace").

Current workaround

First line of the script:

sys.stdout.reconfigure(encoding="utf-8", errors="replace")

Related

• #62310 — statusLine spawned-vs-manual divergence on Windows (different failure: exit 126), same "behaves differently when CC-spawned" theme
• #44563 (closed) — identical cp1252-stdout-crash mechanism in a different CC-bundled subprocess
• #7134 / #64601 — the cp1252 file-corruption cluster: same root codepage cause, unrelated surface