Windows: agent/background-session TUI prints raw un-framed ANSI (dropped ESC) AND cross-session input bleed (2.1.177, WT Preview 1.25)

Summary

On Windows, Claude Code's multi-session claude agents / FleetView dashboard (and attached background sessions) corrupt the bottom chrome (prompt box, session-name label, status/tip rows). Two distinct, reproducible failure modes are present on 2.1.177 — the second is a data-integrity bug, not cosmetic.

1. Raw, un-framed ANSI printed as literal text. The bottom chrome renders SGR sequences as visible text with the leading ESC (0x1B) byte missing — e.g. fragments like [38;2;255;255;255m, [92m, collapsing to repeated garbage such as [555555;36;39M. The session-name label floats to the far-right column. Scrollback stays clean; only the constantly-redrawn bottom chrome is affected. Ctrl+L / resize / reboot force a clean repaint. The visible bytes match a custom statusLine's truecolor output with the ESC byte stripped — pointing at an escape-sequence framing/flush fault on the background-attach/agent render path (a long SGR sequence torn across a write/flush boundary, dropping or misplacing the ESC).

2. Cross-session transcript bleed (severe). A background session's assistant output appeared verbatim in a different foreground session's input stream, rendered as if the user had typed it. This is byte-stream misrouting between daemon-multiplexed sessions — a session-isolation failure, not a paint bug. It recurred multiple times in one sitting.

Environment

• Claude Code 2.1.177 (latest at time of report)
• Windows 11 Pro 26200
• Windows Terminal Preview 1.25 (only WT installed; stable removed)
• PowerShell 7, default font (no font customization)
• Multi-monitor (4-display) workstation
• Daemon roster.json recorded heterogeneous background-PTY worker geometries concurrently (e.g. 119x46 and 120x30).

What was ruled out / tried (Windows-side)

• WT experimental.rendering.forceFullRepaint and experimental.rendering.software — no durable fix (inert on AtlasEngine-only WT 1.24; corruption persists on Preview 1.25 too).
• CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1 — set and active in-process, still corrupts.
• Removing all non-ASCII/emoji from statusLine output — reduced frequency, did not eliminate (the statusLine still emits ANSI SGR color codes).
• claude daemon stop --any (after closing all claude agents viewers) — a clean reset, but corruption recurs on the next escape-dense render, and a fresh daemon + fresh dashboard still corrupted when the same WindowsTerminal.exe process was reused. So it is a recovery step, not a fix.

Why this looks like a regression

The earlier closed issues (#58579, #58925, #59008, #59145) addressed agent-view line-stacking / stale-column artifacts, but this still reproduces on 2.1.177 — and the cross-session input bleed appears to be a separate, more serious defect in the daemon/PTY multiplexing layer.

Asks

1. Reopen the agent-view / background-attach renderer path: the symptom is now un-framed ANSI reaching the screen (dropped/misplaced ESC), not just stale cells — please check for SGR sequences being split across writes/flushes on that path on Windows.
2. Investigate session-to-session byte misrouting in the daemon multiplexer (a background session's output entering another session's input stream) — a data-integrity / isolation issue.
3. Consider a supported full-repaint / synchronized-output mode for agent-view sessions on Windows, plus robustness so a user statusLine emitting valid ANSI cannot desync the chrome.

Happy to provide roster.json, daemon.log excerpts, and a screenshot.