Best possible solution:

Review and land the PR if CI and maintainer UX review agree with adding a persisted WebChat auto-scroll preference; keep the default near-bottom behavior for existing users.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a feature PR rather than a broken-contract bug. Source inspection confirms current main has only the implicit near-bottom policy and no chatAutoScroll setting to reproduce as an existing behavior failure.

Is this the best way to solve the issue?

Yes, the proposed direction is a coherent implementation path: a closed enum setting is normalized through storage, exposed in the existing chat controls, and used at the scroll scheduling boundary. The remaining decision is product/UX approval and normal validation, not a narrow repair.

What I checked:

• Protected maintainer handling: The provided PR context shows author association MEMBER and labels app: web-ui, maintainer, and size: L; repository policy says protected-label or member-authored items stay open for explicit maintainer handling.
• Current main has hard-coded near-bottom chat scrolling: scheduleChatScroll on current main computes shouldStick from effectiveForce, chatUserNearBottom, or the fixed NEAR_BOTTOM_THRESHOLD; there is no persisted mode in this code path. (ui/src/ui/app-scroll.ts:63, 78eb92e62277)
• Current main settings lack chatAutoScroll: UiSettings, defaults, load normalization, and persisted settings on current main include chatShowThinking and chatShowToolCalls but not chatAutoScroll. (ui/src/ui/storage.ts:72, 78eb92e62277)
• PR diff implements the requested feature surface: The PR diff adds CHAT_AUTO_SCROLL_MODES, normalizes/persists chatAutoScroll, renders a desktop/mobile selector, gates scheduleChatScroll by always, near-bottom, and off, and adds focused scroll/settings/render tests. (ui/src/ui/app-scroll.ts:70, 1b8859c8ba7e)
• PR body includes after-fix proof: The PR body reports targeted UI/settings/scroll tests, pnpm check:changed, pnpm ui:i18n:check, pnpm ui:build, and a Vite browser render-helper proof showing two selectors and persistence of chatAutoScroll: "off". (1b8859c8ba7e)
• Feature history sample: Local blame on the central current-main Web UI files points most central scroll/render/settings lines to 439e39626220bef889530c2a342b9f3049e67382; nearby settings history also includes 52370c59980b4c3dce7e1bde22a256d3dfd6b5a7 for browser-local UI settings. (ui/src/ui/app-scroll.ts:1, 439e39626220)

Likely related people:

• Peter Steinberger: Local blame assigns the central current-main chat scroll helper, render helper, i18n strings, and most settings plumbing to commit 439e39626220bef889530c2a342b9f3049e67382; the checkout history is grafted, so this is a routing signal rather than full authorship proof. (role: current-main code provenance; confidence: medium; commits: 439e39626220; files: ui/src/ui/app-scroll.ts, ui/src/ui/app-render.helpers.ts, ui/src/ui/storage.ts)
• Val Alexander: Recent local history shows feat(ui): add browser-local Control UI text size setting, and blame places that nearby settings default in ui/src/ui/storage.ts; this is adjacent to the new browser-local chat setting pattern. (role: recent adjacent settings contributor; confidence: low; commits: 52370c59980b; files: ui/src/ui/storage.ts)

Remaining risk / open question:

• I did not run tests because this sweep is read-only; CI or maintainer validation should confirm the PR body's reported UI test/build results.
• The PR body notes live authenticated WebChat streaming against a real gateway was not tested, so the final landing check should cover that if maintainers want end-to-end stream proof.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 78eb92e62277.