Resizing the window causes visual issues

[Xytronix]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

When resizing the window of a scp session (file transfer to local machine) I am seeing starting to see visual issues.

To reproduce

1. Initiate file transfer with scp -r
2. Resize window to a smaller size and larger size during transfer of multiple files

Expected behavior

No visual issues should occur

Screenshots, videos, and logs

No response

Operating system (OS)

macOS

Operating system and version

26.2

Shell Version

No response

Current Warp version

v0.2026.04.27.15.33.preview_02

Regression

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

Recent working Warp date

No response

Additional context

No response

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

[oz-for-oss]

This issue has been labeled ready-to-implement and is open for contributions involving code changes. If you'd like to tackle it, feel free to open a pull request against this issue. You can also comment @oz-agent on this issue to have the bot draft an implementation PR automatically.

[oz-for-oss]

@Xytronix

Here's what I found while triaging this issue:

This has enough detail to route as a macOS terminal/window-resize rendering bug. It looks related to progress-style output being rewritten while the pane size changes, rather than an scp transfer failure.

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

1. Could you attach a short screen recording of resizing the window while the scp -r transfer is updating its progress output?
2. Does the same visual corruption reproduce in a fresh local Warp tab with another progress command that rewrites one line, or only during scp -r?

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 warp shows visual corruption when resizing a macOS window during active scp progress output, likely in the terminal resize/reflow path for a long-running block..

Triage

This appears to be a Warp-specific visual/rendering bug when resizing a macOS window during an active scp -r transfer. scp progress output commonly rewrites the same terminal line while Warp is also recomputing terminal size and reflowing the active output grid.

Reproducibility

Medium. The report includes OS/version, Warp version, a screenshot, clear resize-during-transfer steps, and confirmation that the issue does not reproduce in other terminals. A short recording would make the exact stale/overwritten cells easier to verify.

Likely area / root cause

The relevant path is terminal resize plus active block grid rendering/reflow:

• app/src/terminal/terminal_size_element.rs sends after-layout terminal size updates.
• app/src/terminal/view.rs builds SizeUpdate, resizes the model, updates scroll position, and emits resize events.
• app/src/terminal/model/terminal_model.rs, app/src/terminal/model/blocks.rs, and app/src/terminal/model/block.rs resize active terminal block grids.
• app/src/terminal/model/grid/resize.rs and app/src/terminal/model/grid/grid_storage/resize.rs reflow grid storage across column/row changes.
• app/src/terminal/model/grid/ansi_handler.rs handles carriage returns and line clearing used by progress output.
• app/src/terminal/writeable_pty/pty_controller.rs and app/src/terminal/local_tty/unix.rs forward size changes to the PTY via TIOCSWINSZ.

The suspected failure is stale/reflowed grid cells or displayed rows not being fully invalidated or recomputed when progress output rewrites a line across a concurrent rows/columns change.

Duplicate check

Enumerated 3,220 open issues. Related reports include #2449 (progress bars rendered incorrectly), #4363 (Linux resize glitches), and #9276 (terminal disappears on maximize), but none match both the macOS scp -r transfer scenario and resize-triggered visual corruption closely enough. Fewer than two likely duplicates were found, so this should not be marked duplicate.

Question reasoning

1. Could you attach a short screen recording of resizing the window while the scp -r transfer is updating its progress output? — The report already includes a screenshot, but the failure is dynamic during resize; a recording would show whether cells smear, overlap, disappear, or fail to clear.
2. Does the same visual corruption reproduce in a fresh local Warp tab with another progress command that rewrites one line, or only during scp -r? — This distinguishes a generic carriage-return/progress-output resize bug from an scp/remote-transfer-specific path.

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

Powered by Oz