Final rendering of many short shell-output lines amplifies frame size and memory use

[Zavianx]

What version of Kimi Code is running?

0.29.2, reproduced from main at d88b3775c9816c15ae82dea8b34794b1e729b5d0.

Which open platform/subscription were you using?

Not applicable. The behavior is in local ! shell-output rendering.

Which model were you using?

Not applicable.

What platform is your computer?

Linux 6.17.0-20-generic x86_64 x86_64, Node.js 24.15.0, Intel Core i9-14900KF.

What issue are you seeing?

When a foreground ! command finishes, Kimi Code replaces the bounded five-line live tail with the command's entire captured stdout/stderr. Output containing many short lines is expanded into a very large terminal frame and requires substantial transient heap, even when the source output is small.

Using the real TUI and ShellRunComponent with a measuring terminal, 50,000 lines of x\n (100,000 source characters, about 0.095 MiB) produced this first completed frame:

Terminal width	Frame write	Amplification over source	Render time on test machine
80	4.39 MiB	46x	45 ms
120	6.29 MiB	66x	48 ms
160	8.20 MiB	86x	49 ms

The byte amplification is deterministic for the output shape and terminal width; the timings are included only as measurements from the platform above.

A component-level stress case with 500,000 x\n lines (about 0.95 MiB source output) added approximately 163 MiB of heap and took approximately 187 ms to render on the same machine. At 120 columns, the full-frame result scales to roughly 63 MiB before it is written to the terminal.

What steps can reproduce the bug?

1. Start Kimi Code in an interactive terminal.
2. Run !yes x | head -n 500000 in foreground shell mode.
3. While it is running, observe that the UI keeps only a short live tail.
4. When the command completes, observe the pause and the large terminal redraw as the full output replaces the live view.

A smaller deterministic case for instrumentation is !yes x | head -n 50000.

What is the expected behavior?

Completing a shell command should not turn a sub-megabyte, short-line output into tens of megabytes of synchronous terminal rendering and large transient heap usage. The final TUI view should remain bounded or incrementally rendered. Full captured output could remain available for transcript storage, export, or an explicit expanded view.

Additional information

The live buffer is capped at 256 KiB, but the source comment explicitly notes that the final view receives the full captured output (source). On completion, renderText() formats, splits, maps, and joins all final lines (source).

Controls checked:

• The running-output path remains bounded and does not throw under large appends.
• Output with fewer lines but the same byte size uses much less heap, isolating line count as a major factor.
• The full Kimi shell-message tests and complete pi-tui suite pass; current coverage exercises large running appends, not the transition to a many-line final view.