Interactive input for aws configure jumps off the pinned bottom command line

[B4Boris]

Summary

Bug: interactive input for aws configure renders in the wrong place in Warp, leaving a large blank area and moving the active input away from the pinned bottom command line.

Problem

When running aws configure in Warp, the terminal view shifts and shows a large blank area. The active input location moves upward so the user has to scroll or look above the visible command line to continue entering values. In some cases the input is effectively off-screen while the command is running.

This appears to be specific to Warp. The same shell setup, including Starship, works normally in the macOS Terminal app.

Expected behavior

While aws configure is prompting for input, the active input area should remain visible and usable, with the command line anchored at the bottom when the terminal is configured for pinned-to-bottom input.

Actual behavior

Running aws configure causes the visible input area to jump upward and leaves a large empty "page" of space in the terminal view. The line where input is expected is no longer where the user would expect it, and typing can happen outside the normal visible bottom command area.

Pressing Ctrl-C to cancel aws configure immediately restores normal behavior and returns the shell to the expected bottom-aligned prompt.

An additional observation: after running exec zsh and then running aws configure, the input still jumps upward, but only to a position a little above the middle of the screen and it remains visible. That suggests a fresh shell partially changes the rendering state, but does not fix the underlying issue.

Reproduction steps or desired workflow

1. Open Warp on macOS.
2. Use zsh with a custom or default (warp) prompt.
3. Run aws configure (or any aws cli command).
4. Observe that the visible input area jumps upward and a large blank area appears in the terminal.
5. Try typing the prompted values and note that the active input area is no longer aligned with the normal pinned-bottom command line.
6. Press Ctrl-C to cancel the command.
7. Observe that the terminal immediately returns to the normal bottom-aligned prompt/input behavior.

Additional variation:

1. Run exec zsh.
2. Run aws configure again.
3. Observe that the input still jumps upward, but less severely than before.

Artifacts

Screenshots attached

Warp version

v0.2026.04.29.08.57.01

Operating system

macOS 26.4.1

[oz-for-oss]

@B4Boris

Here's what I found while triaging this issue:

This appears closely related to #9019, which also involves interactive AWS CLI commands causing the active prompt/input area to scroll away in Warp on macOS. I’m not marking this as a duplicate yet because only one strong matching open issue was found.

I have a few follow-up questions before I can narrow this down:

1. Could you attach a screenshot or short screen recording showing the blank area and where the aws configure prompt/cursor lands?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that interactive AWS CLI prompts in Warp appear to mis-anchor the terminal viewport/input area on macOS, leaving blank space and moving the active prompt away from the expected pinned-bottom position..

Initial triage

This looks like a Warp terminal viewport/input anchoring bug affecting interactive long-running CLI commands on macOS, rather than an AWS-specific failure. The report is detailed enough to route to terminal rendering/input, but a visual artifact would help confirm whether this is exactly the same visual state as related issue #9019.

Evidence

• Repro path is specific: run aws configure on macOS with zsh and a Warp/default or custom prompt.
• The reported behavior is Warp-specific and cancels cleanly with Ctrl-C, which points to active long-running command rendering/scroll state rather than persistent shell corruption.
• A similar open issue, Terminal view gets stuck at the bottom during interactive commands (e.g., aws configure sso) #9019, reports aws configure sso causing interactive AWS CLI input/output to scroll out of view in Warp on macOS. Only one strong duplicate candidate was found, so this triage is not marking the new issue as a duplicate under the current dedupe threshold.

Likely implementation area

• app/src/terminal/view.rs: command execution and long-running input paths call update_scroll_position_locking, and write_user_bytes_to_pty sends typed characters directly to the PTY while updating scroll state.
• app/src/terminal/block_list_viewport.rs: ScrollPositionUpdate::AfterCommandExecutionStarted, AfterWriteUserBytesToPty, and related viewport calculations resolve to FollowsBottomOfMostRecentBlock in pinned-to-bottom mode.
• app/src/terminal/block_list_element.rs and app/src/terminal/model/block.rs: active long-running block cursor rendering happens inside the prompt/command or output grid, so a fix likely needs to keep the active PTY cursor row visible, not only the bottom of the block.

Open questions

The main missing evidence is a screenshot or short recording of the current issue's exact blank-space/cursor placement. That will help distinguish a duplicate of #9019 from a nearby but different pinned-bottom layout regression.

Question reasoning

1. Could you attach a screenshot or short screen recording showing the blank area and where the aws configure prompt/cursor lands? — The report describes a visual layout/scrolling symptom but has no artifact; media would confirm whether this is the same state as Terminal view gets stuck at the bottom during interactive commands (e.g., aws configure sso) #9019 or a distinct pinned-bottom rendering bug.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[B4Boris]

@oz-agent I've attached a 3rd screenshot of the terminal when the aws cli is initiated. Notice how the scroll bar is elevated from the bottom, showcasing that the prompt line is out of scope unless scrolled into focus. I also would like to note that it looks like the triage that was performed consumed credits on my profile. I'm not sure if this is by design or something that needs to be addressed, but I'm a bit confused as to why I should be charged for reporting an issue.

[oz-for-oss]

@B4Boris

Thanks for the third screenshot. It confirms that while aws configure is waiting for input, the scrollbar is elevated and the active prompt is not staying aligned with the pinned-bottom command area. This looks closely related to #9019, but I’m not marking it as a duplicate automatically because the duplicate workflow requires at least two matching open issues.

For the credits/usage concern, that needs account-specific review rather than a public issue-thread triage. Please contact Warp support here so they can investigate privately: https://docs.warp.dev/support-and-community/troubleshooting-and-support/sending-us-feedback

Reasoning

Response mode selected because this run was triggered by an @oz-agent mention on an already-triaged issue and the reporter is providing an extra screenshot plus asking a specific billing/credits question; response mode intentionally does not apply labels. Existing routing still appears appropriate for the product bug portion: bug, os:mac, area:shell-terminal, area:terminal-input, repro:medium.

Code inspection suggests the visual symptom is plausible in the active long-running-command block path. While an output grid is still running, BlockGrid::len derives height from grid_storage().max_cursor_point plus history (app/src/terminal/model/blockgrid.rs:143-151), and Block::output_grid_displayed_height uses len_displayed for the block-list height (app/src/terminal/model/block.rs:1949-1955). GridHandler::finish later truncates content after the cursor and resets max_cursor_point (app/src/terminal/model/grid/grid_handler.rs:1623-1641), which matches the reporter's observation that Ctrl-C/command termination restores normal layout. ViewportState also maps command execution and user writes to scroll_position_after_command_execution, which follows the bottom in pinned-to-bottom mode (app/src/terminal/block_list_viewport.rs:767-789 and app/src/terminal/block_list_viewport.rs:1252-1284). Confidence is medium-low without a local macOS reproduction, but the code path aligns with a large blank area during a PTY-backed interactive prompt.

Duplicate search used gh api --paginate over all open non-PR issues, excluding #10144, and collected 3,274 candidates. The only likely direct match found was #9019 ('Terminal view gets stuck at the bottom during interactive commands (e.g., aws configure sso)'), which overlaps on AWS configure-style interactive input and prompt disappearance. Per the local dedupe contract, fewer than two likely matches means duplicate_of should remain empty and the duplicate label should not be applied.

The billing/credits portion should not be triaged as an actionable public bug because it may require private account usage data; local triage guidance says billing/usage questions should be redirected to Warp support and not pursued in the public issue thread.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz