kiro-cli --tui: TUI becomes extremely slow after extended use #6770
Description
Description
When running kiro-cli chat --tui (via kiro-cli --tui), the TUI becomes extremely slow after a relatively short period of use. Response times and UI interactions degrade noticeably over time, making the tool increasingly difficult to use within a single session.
Environment
| OS | macOS 26.3 (Build 25D125) |
| Hardware | Apple M1 Max, 64 GB RAM |
| kiro-cli version | 1.28.1 |
| Node.js version | v25.8.1 |
| Runtime | Bun (bundled with kiro-cli) |
| Flag used | --tui |
| Command | kiro-cli chat --trust-all-tools --tui |
System performance is not the bottleneck — the machine has ample CPU and memory headroom.
Observed behaviour
The TUI starts responsive but degrades significantly over time. Multiple concurrent tui.js processes were observed running simultaneously, each accumulating substantial CPU time:
PID ELAPSED RSS %CPU COMMAND
44617 27:15 159856 96.5 bun tui.js chat --trust-all-tools --tui
41873 33:35 162256 63.7 bun tui.js chat --trust-all-tools --tui
3596 01:21:37 154896 105.2 bun tui.js chat --trust-all-tools --tui
Notable observations:
- CPU usage climbs to 96–105% per process after extended sessions
- RSS memory per process: ~155–162 MB (stable, so not a memory leak)
- Slowdown appears to be CPU-bound, not memory-bound
- The degradation is progressive — the longer the session, the worse it gets
- Multiple TUI sessions running in parallel each degrade independently
Expected behaviour
The TUI should remain responsive throughout a session regardless of session length or conversation depth.
Additional context
- The slowdown occurs regardless of project size or number of MCP tools loaded
- Restarting the TUI process restores responsiveness temporarily
- The issue appears to worsen with longer conversation histories within a session, suggesting possible unbounded re-rendering or context accumulation in the TUI render loop