Terminal rendering breaks in long conversations - status lines print on new lines instead of updating in place

[ustunb]

Description

After a conversation reaches a certain length, Claude Code's terminal rendering breaks - status updates print on new lines instead of updating in place. This causes the "Thinking..." spinner to spam hundreds of lines, making the interface unusable.

Expected Behavior

Status lines like "✳ Infusing... (esc to interrupt · 5s · ↓ 217 tokens · thinking)" should update in place on a single line.

Actual Behavior

Each status update prints on a new line, resulting in output like:

✳ Infusing…  (esc to interrupt · 5s · ↓ 217 tokens · thinking)

✳ Infusing…  (esc to interrupt · 5s · ↓ 217 tokens · thinking)

✶ Infusing…  (esc to interrupt · 5s · ↑ 217 tokens · thinking)

✶ Infusing…  (esc to interrupt · 5s · ↑ 218 tokens · thinking)

This continues for hundreds of lines. Tool status also affected:

⏺ Bash(ls -la ~/.claude/file-history/ | head -20)
  ⎿  Waiting…

⏺ Bash(ls -la ~/.claude/file-history/ | head -20)
  ⎿  Waiting…

⏺ Bash(ls -la ~/.claude/file-history/ | head -20)
  ⎿  Running…

Observations

• Does NOT happen at start of conversation - only after conversation reaches a certain length
• Restarting Claude Code fixes it temporarily (until conversation gets long again)
• Sometimes stops on its own after a while
• Occurs in both iTerm2 and Terminal.app on macOS
• ANSI escape codes for cursor movement appear to stop working

Environment

• Claude Code version: 2.0.76
• OS: macOS (Darwin 24.6.0)
• Terminals tested: iTerm2, Terminal.app (bug occurs in both)

Impact

• Interface becomes unusable - can't see conversation
• Consumes excessive terminal buffer
• Have to restart Claude Code frequently during long sessions

[ustunb]

Additional clarification from reporter:

The terminal corruption is persistent - it doesn't just affect the spinner/thinking phase. After the bug triggers:

• Every keystroke adds an extra newline
• This continues even after Claude responds
• Affects normal command typing in the terminal
• Persists until terminal is reset or Claude Code is restarted

This suggests terminal state (line mode, escape sequences) is being left corrupted rather than just a rendering issue during streaming.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Status line spinner creates multiple rows instead of updating in place on Windows Terminal #13113
2. [BUG] Spinner animation printing on multiple lines instead of updating in place (Windows) #14630
3. Terminal state corruption after Ctrl+Z suspension - shell freezes, escape sequences displayed literally #12483

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[ustunb]

Root cause identified:

The text input component is leaking its contents to the terminal output stream.

• When the textbox is empty → empty lines are inserted into terminal output
• When typing in the textbox → the characters are echoed/duplicated to terminal

This is NOT an ANSI escape sequence issue. The input field's contents are being written to stdout in addition to being rendered in the UI component. This explains why:

• "Thinking" spinner appears on multiple lines (empty input being echoed)
• User's typing appears duplicated
• The corruption persists (it's continuous leaking, not a one-time state corruption)

Likely a bug in how the Ink/React text input component handles rendering after a certain conversation length triggers some threshold or state change.

[ustunb]

Investigation update:

Investigated potential causes from user customizations:

• ✅ statusline.sh exists but is disabled in settings (statusLine.type: disabled)
• ✅ Hooks are standard Python scripts (commit guards, emoji checker) - no terminal manipulation
• ✅ tweakcc was previously installed but has been uninstalled
• ✅ No other terminal-modifying code found

Conclusion: This is a Claude Code bug, not caused by user customizations.

The text input component leaking to stdout appears to be an internal issue in Claude Code's terminal UI rendering.

[ustunb]

Additional Diagnostic Info from Debugging Session

During a debugging session with Claude, we discovered some additional patterns:

Trigger: Typing During "Orchestrating..." State

The rendering bug seems related to typing in the input field while the orchestration status is updating:

✻ Orchestrating…  (esc to interrupt · 42s · ↓ 1.6k tokens · thinking)

When typing during this state:

• Each keystroke causes a newline + duplicate of the typed text to appear
• The status line appears to conflict with the input field rendering

Bug Stops When:

• The assistant sends a response (status line clears/changes state)
• Suggests a race condition between status bar refresh and input field rendering

Environment Details

• TERM=xterm-256color
• LANG=en_US.UTF-8
• Shell: bash/zsh (occurs in both)

Not the Cause

Ruled out during debugging:

• Custom statusLine setting in ~/.claude/settings.json (disabled it, bug persisted)
• Shell configuration (.bashrc, .zshrc, .bash_profile - nothing Claude-related)
• LSP plugins (pyright installed but not actively running during bug)

Hypothesis

The orchestration status line's refresh mechanism may not be properly coordinating with terminal input handling, causing cursor position or escape sequence conflicts when both are active simultaneously.

[ustunb]

Root Cause Found: Terminal Width

The bug occurs when the status line exceeds the terminal width.

Reproduction Steps

1. Resize terminal to narrow width (~80 columns or less)
2. Trigger an operation that shows a long status line (e.g., TodoWrite with activeForm text)
3. Status line exceeds terminal width
4. Bug appears - status prints on new lines instead of updating in place

Why It Happens

• Status line format: ✽ {activeForm} (esc to interrupt · ctrl+t to hide todos · {time} · ↓ {tokens} tokens · {state})
• With a long activeForm or when todos are active, this easily exceeds 80-100 characters
• Terminal escape sequences (like \r or ANSI cursor positioning) assume the cursor is on a single line
• When text wraps to multiple lines, "move cursor to start of line" only moves to start of the current line, not back to where the status started
• Result: each refresh prints a new partial line instead of overwriting

Suggested Fixes

1. Truncate status line to process.stdout.columns width
2. Or use ANSI sequences to save/restore cursor position (\e[s / \e[u)
3. Or clear wrapped lines before redrawing (need to track how many lines the previous status occupied)

Environment

• Claude Code: 2.0.76
• macOS Darwin 24.6.0
• Affects both Terminal.app and iTerm2