MoonshotAI / MoonshotAI/kimi-code

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

Open
#2,320 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
7.5k
Forks
1.2k
Avg merge
11h 53m
Merged PRs (30d)
350

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with apps/kimi-code/src/tui/components/messages/shell-run.ts, especially the completion path and renderText() at the referenced lines. Read the existing full Kimi shell-message tests and pi-tui suite, then reproduce with !yes x | head -n 50000. Done means the completed view stays bounded or incremental without the measured frame-size and heap amplification.

Written by the indexing model from the issue text.

Assessment

Tech stack
shell, typescript
Domain
cli, performance
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.