Status line content leaks into main output area during streaming

Bug Report: Status Line Content Leaks Into Main Output Area

Summary

Custom status line script output intermittently appears as visual artifacts in the main conversation area during streaming responses, rather than staying confined to the status line region at the bottom of the terminal.

Environment

• Claude Code Version: 2.1.17
• OS: macOS (Darwin 25.2.0)
• Terminal: Ghostty
• Model: Opus 4.5

Description

When using a custom status line script (configured via /statusline), fragments of the status line content randomly appear mid-screen while Claude is generating responses. The artifacts are partial text from the status line, specifically from progress bar labels like | B (from "Block [") or | C (from "Ctx [").

The artifacts appear to be "burned in" at incorrect cursor positions during streaming output.

Steps to Reproduce

1. Configure a custom status line script with multiple lines containing ANSI color escape sequences and progress bars
2. Start a conversation and ask Claude a question that generates a multi-paragraph response
3. Observe the main output area during streaming - artifacts from the status line appear randomly mid-screen

Expected Behavior

Status line content should only appear in the designated status line area at the bottom of the terminal, regardless of:

• The content/complexity of the status line output
• The order of lines in multi-line status output
• Whether Claude is actively streaming a response

Actual Behavior

Fragments of status line content (especially from lines containing progress bars with many escape sequences) appear as visual artifacts in the main conversation area during streaming.

Key Finding: Output Order Affects Artifact Frequency

During debugging, we discovered that the order of lines in the status line output affects whether artifacts appear:

# This order produces FEWER artifacts:
OUTPUT="${LINE3}\n${LINE1}\n${LINE2}"  # Gamification first (has progress bar)

# This order produces MORE artifacts:
OUTPUT="${LINE1}\n${LINE2}\n${LINE3}"  # Model info first (no progress bar)

This suggests a timing/race condition in the terminal renderer. When a "heavier" line (with more escape sequences) is output first, it may give the renderer time to properly establish cursor state before subsequent lines render.

Hypothesis

The status line update occurs while Claude is streaming output to the main area. There appears to be a race condition where:

1. Claude Code saves cursor position
2. Moves cursor to status line area
3. Writes status line content
4. Race condition: Some escape sequences or content get written before cursor is properly positioned
5. Restores cursor position

The partial content ends up at the wrong screen coordinates.

Relevant Release Notes

These past fixes suggest this is a known problem area:

• v2.1.5: "Improved terminal rendering stability by preventing uncontrolled writes from corrupting cursor state"
• v2.1.0: "Fixed visual artifacts in ink2 mode when nodes become hidden"
• v2.0.70: "Reduced terminal flickering"

Workarounds Attempted

• Adding exec 2>/dev/null to suppress stderr - did not fix
• Using printf '%b\n' instead of echo -e for atomic output - did not fix
• Removing progress bars from certain lines - reduced but did not eliminate
• Changing line output order - affects frequency but doesn't eliminate

Screenshots

[Attach screenshots showing artifacts appearing mid-screen with status line fragments visible]

Status Line Script

The script outputs 3 lines with ANSI 24-bit color codes and Unicode characters (emojis, progress bar blocks). Full script available on request.

Suggested Fix

The status line renderer should ensure atomic cursor save/write/restore operations that cannot be interleaved with main output streaming, regardless of status line content complexity or timing.