Your own scrolling always wins (the reader owns the view)

What it is

A session's transcript changes while you read it: replies stream in, images finish loading, older turns render, the keyboard opens, the header grows. Omniscio places the transcript for you when you open a session (at the live bottom for a running session, at the start of the reply you came to read, and so on). The moment you move the transcript yourself, that placement is over: nothing automatic moves it again during that visit, with one exception — if you are sitting at the very bottom, new output keeps you at the bottom so you can watch it arrive.

It applies on the phone and on desktop.

What counts as "you moved it"

• Scrolling with a finger, the mouse wheel or a trackpad.
• Scroll keys (Page Up / Page Down, Home / End, the arrow keys, Space) outside a text box.
• Pressing and dragging the transcript's scrollbar.
• Any scroll control: the up and down arrows, the "N more replies" pill, the press-and-hold on the down arrow, the step keys (Shift+Up / Shift+Down), Ctrl+Home / Ctrl+End, and jumping to a search result.

Scrolling that you did not do — content collapsing, the browser keeping your place while something above you renders — never takes the view on your behalf.

Where you end up

• You moved away from the bottom — the transcript stays exactly where you put it. A late image, a new reply, the keyboard opening, the header changing, a turn finishing: none of them move it. The down arrow shows, so jumping to the latest is always one tap away.
• You moved to the very bottom (within about 32 pixels — the same line at which the down arrow appears) — new output keeps you pinned to the bottom, the way a chat should.

What hands the view back to the app

• Opening the session fresh, or coming back to it after switching away — it lands the usual way for its state.
• Sending a message yourself — you are taken to the bottom to see it, and follow the reply.
• Jump to latest (the down arrow, or its hold on the pill) — you follow new output again.
• Scrolling back down to the bottom yourself.

A scheduled message you set up with Send Later still scrolls into view when its card appears; one the Inbox Pilot, another agent or a scheduled job queued only does so if you have not scrolled away from the bottom yourself.

Why it works this way

Earlier, each automatic correction guessed on its own whether you were still scrolling, from how long ago your finger last moved (a few seconds). Someone who scrolled and then read looked idle, and a tap on a scroll control was never seen at all, so a correction could take the page back — the reported "when I scroll up on mobile it still jumps me back down". Now one fact decides it for every correction: who moved the view last.

For agents and developers

• The engine is useSessionScroll in useSessionScroll.ts. The state is landing / following / reading; every automatic write asks engineMayMove; the decisions are the pure nextViewControl and engineMayMoveFor in scroll-classifiers.ts.
• The scroll tape records each handover as [scroll:reader] <from> -> <to> and each refused move as HOLD reader is reading (or following), so a report of an unwanted jump can be traced.
• The rule is the-reader-owns-the-view-once-they-move-it in session-scroll-contract.md; a build guard (session-scroll-reader-control.test.ts) refuses any new automatic scroll write that does not ask.
• There is no setting: this is how scrolling is meant to behave.

Where to find it

How it behaves

Related

• Real Conversation Layout — what the transcript shows and hides.
• More replies below — the unread-count pill that jumps the view to the latest.
• Send a message — sending is one of the actions that hands the view back to auto-scroll.