TUI renders many characters as corrupted/garbled glyphs

Summary

A large fraction of characters in the TUI transcript render as corrupted/garbled glyphs (boxes / mojibake), making output very hard to read. It is not isolated to one line — it affects normal model output, tool-call summary lines, and the status panels.

What it looks like

Many letters are replaced with garbage glyphs. Examples from a single session (intended → rendered):

• browser → b⊠o⊠se⊠
• persistently → pe⊠siste⊠tly
• continue → co⊠ti⊠ue
• Firefox → Fi⊠efo⊠
• Done. Built and committed... → Do⊠e. ⊠uilt a⊠d co⊠⊠itted...

It appears to hit a consistent set of characters (looks like n, r, m, w, capital A/B, etc.) rather than being random, which suggests a glyph/encoding/font-fallback issue rather than corrupted data. The selected/highlighted region at the top is even more heavily mangled.

Impact

The transcript is barely legible. Tool summaries, the final assistant message, and side panels (Context meter, OpenAI limits, KV cache) are all affected.

Environment

• Repo: 1jehuang/jcode (Coding Agent Harness)
• Surfaced while running a local Vite + TypeScript + Phaser scaffold session in the TUI.

Notes / questions to investigate

• Is this a terminal font / glyph-fallback problem, a Unicode width/encoding bug in the renderer, or corruption in how output is written to the screen buffer?
• Does it reproduce across terminals (e.g. iTerm2 vs Apple Terminal vs Ghostty) or only one?
• Does it correlate with a specific font or with non-ASCII/emoji glyphs being mixed into the same line?

A screenshot is available (drag-and-drop into this issue) showing the full corrupted transcript.

No source file, test, or renderer entry point is named. First reproduce the corruption in the TUI and compare iTerm2, Apple Terminal, and Ghostty, including different fonts and mixed non-ASCII output. Done means identifying whether the cause is terminal fallback, Unicode width handling, or screen-buffer output, with a regression check for the affected transcript and panels.