← graph

fix-pty-scrollback

Fix: PTY scrollback duplicates on initial chat render (no resize needed)

Metadata

Statusdone
Assignedagent-1084
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Created2026-04-29T11:37:31.888867410+00:00
Started2026-04-29T12:14:47.564681711+00:00
Completed2026-04-29T12:45:43.864547708+00:00
Tagsbug,tui,pty, eval-scheduled
Eval score0.70
└ blocking impact0.75
└ completeness0.65
└ constraint fidelity0.85
└ coordination overhead0.81
└ correctness0.72
└ downstream usability0.62
└ efficiency0.76
└ intent fidelity0.43
└ style adherence0.82

Description

Description

User reports: after fix-tui-pty (commit e0f5d029b) shipped, the duplication symptom STILL occurs — but now without any window resize trigger. On opening a chat, the scrollback 'loops a bit and then settles' so the user can scroll. This is a different code path from the resize fix that just landed.

User quote: 'still getting bad repetition in scrollback now. no resize at all. chat scrollback loops a bit and then settles so i can scroll...'

Likely root cause hypothesis

The resize fix (fix-tui-pty / commit e0f5d029b) addressed re-wrap on dimension change. But the initial chat-tab render path may have its own redraw loop:

  • Buffer is hydrated from disk (chat_dir_for_ref / chat-history JSONL)
  • Scrollback gets rendered, then re-rendered as new content streams in
  • Initial frames may double-emit the tail (matching the same kind of duplication seen on resize)

OR it's a duplicate-render path tied to streaming_text + finalized response (recent commit 572a28d37 'fix-pty-output' touched this; might be regressed).

Repro

  1. Open the wg TUI on a project with existing chat history
  2. Click into a chat tab that has multi-screen scrollback
  3. Observe: the scrollback briefly shows duplicated content, settles after some time, then is scrollable

Goal

Diagnose + fix. Likely candidates:

  • Initial-render path in src/tui/ that rebuilds the chat buffer when a tab becomes active
  • Streaming_text vs finalized message rendering — the same content may be emitted as a streaming chunk THEN as a finalized message, both going to the visible buffer
  • Hydration replay: chat history file is read and re-emitted into the PTY/scrollback, on top of whatever was already shown

Cross-reference recent commits:

  • e0f5d029b (fix-tui-pty) — the resize fix that just landed; do NOT undo it
  • 572a28d37 (fix-pty-output) — earlier 'stop chat tab from rendering streaming_text + finalized response twice'
  • b07601fcd (tui-detail-view) — recent TUI render changes

Look for any path where the same content is appended twice to the rendered scrollback during initial chat-tab activation.

Validation

  • Failing test written first: simulate chat-tab activation with multi-screen history; assert rendered scrollback contains each message line exactly once
  • Repro from the user's steps no longer shows the 'loops a bit and then settles' behavior — initial render is correct on first paint
  • No regression of fix-tui-pty (resize still works correctly)
  • Permanent smoke scenario added covering the initial-render path; this task id in owners
  • cargo build + cargo test pass
  • cargo install --path . was run before claiming done
  • LIVE smoke: actually open the TUI on this project, click into a chat with history, confirm no duplication. Record observation in task log.

Depends on

Required by

Log