TUI: long tool-result content bleeds into right sidebar gutter (visual corruption)

[Hmbown]

Symptom

When a long tool result (e.g. a todo_write echoing back its full JSON payload) renders in the transcript, character fragments of the content (heli, hel, h`li, ent, etc.) appear as a vertical column of garbage inside the right sidebar, in the gutter regions between the Plan / Todos / Tasks / Agents widget borders.

Where a sidebar widget is drawn, the leak is hidden (the widget overdraws). Where there is no widget on a row (the seams between widgets, or rows where a widget has scrolled past its content), the fragments leak through.

Reproduce: open the TUI, run a turn that emits a long todo_write tool result whose content field is something like a long string (e.g. "hello world hello world ..."). The raw result: line is then long enough that wrapped continuations end up rendering past the chat pane's right edge.

Suspect

Layout itself is correct — crates/tui/src/tui/ui.rs:2761-2768 splits chunks[1] horizontally into chat_area + sidebar_area, and ChatWidget::render (crates/tui/src/tui/widgets/mod.rs:136-160) renders a Paragraph to self.content_area. ratatui clips a Paragraph to the area it's given, so the bleed should not be possible from that path alone.

That leaves three plausible paths:

1. Direct buf.set_string writes outside content_area. The streaming / live-update path may write cells using absolute coordinates without re-clipping to chat_area. Worth auditing crates/tui/src/tui/streaming.rs, crates/tui/src/tui/transcript.rs, and crates/tui/src/tui/markdown_render.rs for any cell writes that take a Buffer and an x derived from something other than area.x.
2. Transcript cache wrapped to the wrong width. app.transcript_cache.ensure(..., content_area.width.max(1), ...) (mod.rs:65) wraps lines to the chat width — but a single wide tool-result chunk that's pre-wrapped by the renderer (e.g. JSON pretty-printed at a fixed width) might not get re-wrapped. The Paragraph would then truncate, but if anything else writes those overflowed graphemes (a hover/selection layer, scrollbar, status overlay), they'd land in the sidebar.
3. Stale buffer cells from a prior frame. Less likely under normal ratatui usage (full redraw each frame), but worth confirming the frame is being fully cleared and that no app.view_stack overlay paints partial rows that get torn when chat content shrinks.

Repro environment

• deepseek-tui 0.5.0
• deepseek-v4-pro, YOLO mode, max reasoning effort
• Terminal width ~165 columns

Screenshot

(attached in the issue thread that filed this — long line result: Todo list updated (2 items, 0% complete){ "items": [ { "id": 1, "content": " hel... followed by a vertical column of heli / hel / h`li fragments inside the sidebar gutter)

Acceptance

• A long single-line tool result no longer produces character fragments inside the sidebar area at any terminal width.
• A test that renders ChatWidget with a 5,000-char single-line tool result + a sidebar split asserts the sidebar's Buffer cells are untouched outside the widget regions.

[Hmbown]

Second repro — adds two new clues

A second occurrence of the same bug shows two extra symptoms that significantly narrow the cause:

1. Left edge is clipped by exactly 1 column, globally.

• Transcript: ssistant (s/b Assistant), olo (s/b yolo), rite a task or use /. (s/b Write a task or use /.).
• The composer placeholder is affected too, so this is not chat-specific — every region is shifted left by 1 column.

2. The sidebar gutter now leaks ||, i|, ent, l, i fragments between the Plan / Todos / Tasks / Agents widgets. The || and i| strongly suggest leftover widget borders (│) from a previous frame where sidebar widget rects were positioned 1 column to the right of where they're being drawn now.

Updated theory

This points away from "a non-paragraph render path writes outside its area" and toward a stale frame buffer + 1-column horizontal misalignment after a terminal resize or sidebar-width change:

• Before the resize/toggle: chat_area was wider, sidebar widgets were positioned at column N+1, with right border at column M+1.
• After the resize: chat_area is now wider by 1, chat content gets re-wrapped/re-rendered to the new width, but somehow renders shifted 1 left. Sidebar widgets now sit at column N, M — and the cells at column N+1, M+1 (the OLD widget border positions) never get overdrawn this frame.
• ratatui's Frame::render_widget only writes the cells it draws into; cells outside any widget's area for the current frame retain their value from the last frame. If the terminal isn't fully cleared between frames, stale border + content cells survive.

Things to check:

1. Is the terminal being fully cleared every frame, or only on resize? Look for terminal.clear() / terminal.draw() usage in crates/tui/src/tui/app.rs event loop. If clear-on-resize is missing or mis-timed, this is exactly the symptom.
2. SIDEBAR_VISIBLE_MIN_WIDTH boundary (ui.rs:2753). If the terminal width hovers near the threshold where the sidebar appears/disappears, transitioning frames could leave stale cells from the prior layout.
3. sidebar_width saturation arithmetic at ui.rs:2757-2759:

   let sidebar_width = preferred_sidebar.max(24).min(chunks[1].width.saturating_sub(40));

   At certain widths this can produce a sidebar that's 1 column off from a previous frame's value.
4. app.last_transcript_area caching in widgets/mod.rs:53,89 — does any downstream code (selection, scroll mapping) use the cached Rect from the previous frame against the current frame's buffer?

A terminal.clear() on every resize event, plus an audit of width-dependent caches that don't invalidate on width change, would likely fix both the 1-column shift and the gutter leak.

(Original screenshot showed the gutter leak only; this second screenshot makes the global 1-column left-shift visible because the leftmost characters of common words are missing.)

[Hmbown]

Diagnosis update — resize handling is fine

Investigated the suspect from the previous comment: crates/tui/src/tui/ui.rs:908-911 already does terminal.clear() + app.handle_resize() on every Event::Resize. app.handle_resize() (app.rs:1074) invalidates the transcript cache, the cached transcript area, and selection endpoints. So the "stale frame after resize" theory doesn't hold — the obvious clear path is wired up.

That means the leak has to come from one of:

1. A non-resize layout transition that doesn't clear, e.g. the sidebar visibility threshold (SIDEBAR_VISIBLE_MIN_WIDTH) being crossed by the composer expanding/collapsing or the focus mode changing. None of those paths call terminal.clear() today.
2. A custom rendering path that bypasses the Frame buffer. Worth grep'ing for any crossterm::execute!/queue! calls outside the alternate-screen setup that write directly to stdout while the main draw loop is also active. A streaming markdown writer that goes around ratatui would do exactly this.
3. A Buffer being rendered into a Rect it doesn't fully cover. ratatui zeroes cells in Buffer::reset() at the start of each frame, so this should be impossible from the standard widget path — but if any code path passes a stale/cached Rect into a custom widget render, the unwritten cells would diff to "no change" against the previous frame's content, leaving it visible.

Best-effort diagnosis without a live repro is hitting its limit; closing this comment thread to stop speculating. Repro recipe to capture next time: RUST_LOG=deepseek_tui=trace deepseek-tui --yolo, run a long todo loop, watch for the moment the bleed appears — the trace log should show whether a resize/clear happened just before, or not.

[Hmbown]

Snapshot regression tests added in v0.5.1 via commit 7a85f18.

Two tests now lock in the acceptance criterion:

1. chat_widget_does_not_bleed_into_sidebar_for_long_tool_result constructs a todo_write-shaped output (status line + multi-kilobyte JSON payload with a 5,000-char content string) and asserts no cells outside chat_area are touched, at the widths reported in the bug (80, 120, 165, 200 cols).
2. chat_widget_reserves_scrollbar_gutter_when_scrollbar_visible verifies the scrollbar coexists with content along the right edge instead of overdrawing the penultimate column.

Investigation: I went through every direct buffer-write site (streaming.rs, transcript.rs, markdown_render.rs, selection.rs, scrolling.rs) plus ratatui's Paragraph::render_text and LineTruncator and confirmed all paths clip to the rendering area. The probe long_tool_result_lines_fit_requested_width also confirms the line generator never produces lines wider than the requested width. Most likely an earlier refactor on the fix(#37) / feat(#34) series fixed the underlying bleed; the tests are the regression guard going forward.

Closing as the acceptance criterion (regression test exists + currently green) is satisfied. Reopen with a fresh repro recording if it ever comes back at a specific width.