# PR Draft: Fix sticky auto-scroll during streaming chat responses Fixes #308 ## Summary This change makes chat auto-scroll easier to escape while assistant output is still streaming. The goal is to stop the viewport from repeatedly pulling the user back toward the bottom once they begin scrolling upward to inspect earlier content. ## Why Before this change, streaming updates could keep reasserting bottom-follow behavior during active rendering. That made auto-scroll feel sticky and forced users to scroll repeatedly or forcefully just to review earlier parts of an in-progress response. The intended behavior is simpler: once the user scrolls upward to leave follow mode, the UI should respect that decision instead of fighting it during subsequent stream updates. ## What Changed 1. Removed render-time force-bottom behavior from the shared follow-scroll helper path. 2. Updated streamed reasoning output to restore scroll without forcing the viewport back to the bottom. 3. Updated streamed tool-call output to use the same non-forcing restore behavior. ## Scope Boundaries Included: - Sticky auto-scroll behavior during streamed chat output - Shared follow-scroll behavior used by streamed nested panes - Reasoning and tool-call streaming paths that reused the same forced follow behavior Not included: - A full rewrite of the virtualized message list follow model - Broader scroll UX changes outside the streaming follow/escape behavior - Unrelated UI or plugin configuration changes in the worktree ## Technical Notes The core problem was not basic auto-scroll itself, but a render-time path that could keep forcing bottom-follow behavior while new streamed content was arriving. That meant a user's attempt to scroll upward could be overridden repeatedly by subsequent stream updates, which is why the auto-scroll felt sticky. The fix removes that override and keeps render-time restoration dependent on the current follow state instead. ## Files Changed - `packages/ui/src/lib/follow-scroll.tsx` - `packages/ui/src/components/message-block.tsx` - `packages/ui/src/components/tool-call.tsx` ## Verification Performed: 1. Reproduced the sticky auto-scroll behavior with a long multi-line streaming response. 2. Verified that scrolling upward during streaming now disengages follow more naturally in the affected streamed panes. 3. Ran `npm run typecheck --workspace @codenomad/ui`. 4. Ran `npm run build --workspace @codenomad/ui`. Build note: - The UI typecheck passes. - The UI build succeeds. - The build still emits existing third-party and chunk-size warnings unrelated to this change. ## Risks and Follow-up 1. The broader scroll-follow model is still more heuristic-heavy than ideal, so there may be future follow-up work to simplify it further. 2. This PR intentionally applies the smallest targeted fix to the known snap-back path instead of rewriting the full chat scroll system. --------- Co-authored-by: Shantur Rathore <i@shantur.com>
CodeNomad UI
This package contains the frontend user interface for CodeNomad, built with SolidJS and Tailwind CSS.
Overview
The UI is designed to be a high-performance, low-latency cockpit for managing OpenCode sessions. It connects to the CodeNomad server (either running locally via CLI or embedded in the Electron app).
Features
- SolidJS: Fine-grained reactivity for high performance.
- Tailwind CSS: Utility-first styling for rapid development.
- Vite: Fast build tool and dev server.
Development
To run the UI in standalone mode (connected to a running server):
npm run dev
This starts the Vite dev server at http://localhost:3000.
Building
To build the production assets:
npm run build
The output will be generated in the dist directory, which is then consumed by the Server or Electron app.
Debug Logging
The UI now routes all logging through a lightweight wrapper around debug. The logger exposes four namespaces that can be toggled at runtime:
sse– Server-sent event transport and handlersapi– HTTP/API calls and workspace lifecyclesession– Session/model state, prompt handling, tool callsactions– User-driven interactions in UI components
You can enable or disable namespaces from DevTools (in dev or production builds) via the global window.codenomadLogger helpers:
window.codenomadLogger?.listLoggerNamespaces() // => [{ name: "sse", enabled: false }, ...]
window.codenomadLogger?.enableLogger("sse") // turn on SSE logs
window.codenomadLogger?.disableLogger("sse") // turn them off again
window.codenomadLogger?.enableAllLoggers() // optional helper
Enabled namespaces are persisted in localStorage under opencode:logger:namespaces, so your preference survives reloads.