Bug
When a kimi-code session produces enough streamed output (tool calls, thinking blocks, background task updates, etc.) to push the live region past the terminal height, the bottom chrome (input box, footer, todo panel) leaves duplicate stacked frames on screen and in scrollback.
Root cause
pi-tui renders onto the terminal's main screen buffer and uses incremental/differential updates. When content grows, the terminal auto-scrolls the whole visible screen; the previous chrome frame is pushed upward and pi-tui redraws a new chrome frame at the bottom. Because the chrome is part of the rendered buffer, the old frame remains visible, creating stacked copies of the footer/input/todo list.
This is the same underlying issue reported upstream in pi-tui:
- earendil-works/pi discussion #1712 – request for alternate screen buffer support
- earendil-works/pi issue #3083 – spinner rows leaking into scrollback on growth
Fix we applied
In our fork we fixed it by switching the TUI to the terminal alternate screen buffer while kimi-code is running, so TUI frames never pollute the terminal's normal scrollback. We kept the chrome as a pinned bottom overlay and added a ChromeAwareContainer wrapper that pads the transcript so new messages render above the overlay rather than underneath it.
Reference commit: thecannabisapp/kimi-code@c3b867d
Suggested action
Consider applying the alternate-screen-buffer fix upstream, or wait for pi-tui to add native alternate-screen support. Until then, users on the official build will continue to see stacked chrome frames in long sessions.
Bug
When a kimi-code session produces enough streamed output (tool calls, thinking blocks, background task updates, etc.) to push the live region past the terminal height, the bottom chrome (input box, footer, todo panel) leaves duplicate stacked frames on screen and in scrollback.
Root cause
pi-tui renders onto the terminal's main screen buffer and uses incremental/differential updates. When content grows, the terminal auto-scrolls the whole visible screen; the previous chrome frame is pushed upward and pi-tui redraws a new chrome frame at the bottom. Because the chrome is part of the rendered buffer, the old frame remains visible, creating stacked copies of the footer/input/todo list.
This is the same underlying issue reported upstream in pi-tui:
Fix we applied
In our fork we fixed it by switching the TUI to the terminal alternate screen buffer while kimi-code is running, so TUI frames never pollute the terminal's normal scrollback. We kept the chrome as a pinned bottom overlay and added a ChromeAwareContainer wrapper that pads the transcript so new messages render above the overlay rather than underneath it.
Reference commit: thecannabisapp/kimi-code@c3b867d
Suggested action
Consider applying the alternate-screen-buffer fix upstream, or wait for pi-tui to add native alternate-screen support. Until then, users on the official build will continue to see stacked chrome frames in long sessions.