[Bug] TUI rendering corruption in Tmux: overlapping text output and screen state mismatch
Status Fixed / completed
Reported on v2.1.169
Maintainer reply None cached
Activity 11 comments · opened Jun 9, 2026 · closed Jun 11, 2026
Bug Description
I am running claude in Tmux 3.5a in ghostyy on a macbook. Text output is consistently getting messed up, with TUI elements rendering over the top of each other. It is like the internal representation of the screen no longer matches. I do not need to resize the pane for this to happen. This is making claude impossible to use - as I cannot monitor what it is doing.
This is an innocuous example where the input is rendered twice. It often corrupts the entire screen.
<img width="1250" height="288" alt="Image" src="https://github.com/user-attachments/assets/61bde6d8-5826-46f0-9355-a84a111f8ee6" />
Environment Info
- Platform: darwin
- Terminal: tmux
- Version: 2.1.169
- Feedback ID: ee3b8f15-64bc-4f73-bfe8-b77b63da612a
Errors
[]Showing cached comments. Read the full discussion on GitHub ↗
10 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Reproduced this in tmux 3.5a on macOS as well. The rendering corruption makes long-running agent sessions effectively unmonitorable — you lose track of whether the agent is prompting, executing, or waiting, which is the entire point of watching the TUI.
The pattern I see: it seems to worsen over long sessions (3h+) rather than appearing immediately. Resizing the pane used to clear it, but as you note, that's no longer reliable. Switching to a new tmux window and attaching fresh helps as a workaround but breaks any in-session context you were tracking visually.
If this is a cursor positioning issue in the TUI renderer, it might be worth checking whether the fix in the agent-view session refresh path introduced any terminal state assumptions that don't hold in tmux's alternate-screen mode.
One cause of this issue may also be related to viewing tmux scroll history. I noticed just now it became corrupted when I scrolled. I wonder if updates are being swallowed while scrolling so the pane and internal representation are immediately out of sync once exiting the tmux history.
Pure speculation.
Running into this also. Ctrl+L does heal it temporarily. It seems to be related to the verbing... spinner in some way because once thats going Ctrl+L wont save you any more until things stop.
So I have similar, but much more debug/logging info on https://github.com/anthropics/claude-code/issues/66593
I'm running into this running Claude Code in tmux but also having the same issue running Claude on a remote server via an ssh connection (without using tmux).
I also have this issue — it often garbles output and forces me to Ctrl-C twice and
claude --resume <session>to make the output readable again. Ctrl-L does seem to help, thank you @jhogendorn! This is quite a UX regression headache; hoping it can be resolved soon.Version: 2.1.170
Closing this as a duplicate of https://github.com/anthropics/claude-code/issues/29937 - although note that that issue is labeled linux where as this is definitely a mac issue too.
please prioritise this issue its unusable :(
Turning off vim editing mode fixes it for me. Looking forward to getting it fixed since I really like vim mode