hermes - 💡(How to fix) Fix Create new issue Blank issue · Choose a different template Add a title * Title Add a description Markdown input: edit mode selected. Write Preview

Environment

• Hermes commit: ea6eaabd8
• Platform: Windows 11 desktop app
• Frequency: ~50% of turns

Symptoms

When the assistant sends a response, the transcript viewport does not auto-scroll to the bottom. The user's own messages get pushed above the visible area, and the viewport stays at a stale scroll position.

Likely cause

Virtual transcript sticky/follow-to-bottom logic in ui-tui/src/hooks/useVirtualHistory.ts. Recent related commits: 2a75bec60, 0277194e3, 511b8e232.

Steps to reproduce

1. Open Hermes Desktop on Windows
2. Have a normal multi-turn conversation
3. After some assistant responses, the viewport fails to follow — user messages are pushed out of view

Workaround

CLI mode (hermes without --tui) is not affected.

Technical context

The TUI uses a virtual-scrolling transcript with a "sticky" mode (auto-follow-to-bottom). The relevant code path:

1. useVirtualHistory.ts — shouldSetVirtualClamp() decides whether to pin the viewport at bottom
2. When sticky=true and no recent manual scroll, visibleTop = Math.max(0, total - vp)
3. During live streaming, liveTailActive gates the clamp behavior
4. scrollRef.current?.isSticky() is read via useSyncExternalStore

Hypothesis: sticky mode is being broken mid-turn — isSticky() returning false when it should be true, or shouldSetVirtualClamp incorrectly returning true (clamping the scroll position) during live assistant output. The recent resize-aware fixes (2a75bec60, 0277194e3) may have introduced a race where sticky state loses sync with the actual scroll position during content growth.

Observation notes

• Not correlated with window resize — happens mid-conversation
• User is NOT manually scrolling up before the bug occurs
• CLI mode (pure terminal, no xterm.js wrapper) does not reproduce — suggests the issue is in the Ink/React render layer, not the data layer

@brooklyn-bb