Terminal height doesn't account for uncollapsed input command height in ssh

[SeseMueller]

Dupe Check

• I have searched Warp bugs and there are no duplicates

Describe the bug

When in an ssh session, commands like top believe that the terminal is higher that it actually is; they use more space than is visible, because it is hidden under the command input, like top.
If the command input is collapsed with the up-arrow in the middle, it works as expected, but extending it back doesn't change anything.

To reproduce

1. Start an SSH session to a semi-busy server
2. Run top
3. Scroll all the way down
4. => the very top of the output is cut off

Expected behavior

The top of the output should not be cut off.
The commands probably get the height of the pane, not of the output section.

Screenshots

(This is scrolled down all the way down with extended command input)

(This is with collapsed command input: works as expected)

Operating system

MacOS

Operating system and version

15.0.0

Shell Version

zsh 5.9 (arm65-apple-darwin24.0)

Current Warp version

v0.2024.09.24.08.02.stable_01

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

The same error occurs (around the first 1,75 lines are cut off), even when the pane is split vertically.

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None