Legacy Console-API apps: scrolling and flicker are mutually exclusive in a Warp pane

[malizd]

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

Legacy Console-API apps: scrolling and flicker are mutually exclusive in a Warp pane

Warp version: v0.2026.08.12.21.54.stable_00 (Windows)
OS: Windows 11 Business 10.0.22631
Affected app: File Commander/W 2.50 (fcw.exe) — 64-bit Win32 console app

Summary

A full-screen console application that uses the classic Win32 Console API renders
incorrectly in a Warp pane, and the two failure modes cannot be avoided at the same
time. The identical binary, over the same ConPTY, renders correctly in Windows
Terminal — so this appears to be Warp's renderer rather than ConPTY.

The app in question paints with WriteConsoleOutputW, scrolls with
ScrollConsoleScreenBufferA, reads keys with ReadConsoleInputW, and reads the
console dimensions once at startup. It does not use VT sequences and does not
enter the alternate screen buffer itself.

Problem 1 — region scroll does not render unless the app resizes the console

With the app's configured Lines/Columns set to exactly the pane's grid, scrolling
the file list does not render: the selection reaches the bottom row and only that row
changes. Every row above it stays put, although the application's internal state has
scrolled correctly.

Scrolling renders correctly only when the app's configured size differs from the
grid, so that its SetConsoleScreenBufferSize call actually changes the size. The
magnitude does not matter — one column is enough.

Problem 2 — that same resize is what flickers

When the app does resize the console, the pane flickers continuously until the list is
scrolled to the bottom, at which point it settles.

So:

App size vs pane grid	App resizes console?	Scrolling	Flicker
exact match	no	broken	none
any inset (1 or 4 cols)	yes	works	yes

There is no configuration that gives both.

Alternate screen

Because the app never emits CSI ?1049h, Warp keeps the pane in block mode, where a
region scroll has no meaning — only the bottom line ever moves. Emitting ?1049h from
the shell before launching the app is what makes region scrolling render at all.

appearance.full_screen_apps.alt_screen_padding interacts with this. With
{ custom = { uniform_padding = 0.0 } } the pane is resized on alt-screen entry
(138 -> 142 columns in our case); an app that reads its size once at startup must not
be launched until that resize has settled. With match_blocklist no resize occurs.

Problem 3 — PageUp/PageDown never reach the application

PgUp/PgDn are consumed by Warp's input editor and never reach the PTY, so a full-screen
app cannot use them for paging. Setting terminal:scroll_up_one_page and
terminal:scroll_down_one_page to none in keybindings.yaml does not release them,
which suggests the editor handles these keys outside the keybinding system. Arrow keys
are delivered normally, so this is specific to PgUp/PgDn.

Expected

A pane running a full-screen console application should render ScrollConsoleScreenBuffer
region scrolls without requiring the application to resize the console, and should not
flicker when it does resize. PgUp/PgDn should be forwardable to the running application.

Reproduction

1. Install File Commander/W (https://www.dpaehl.de/ or any Norton Commander-style
   Win32 console file manager that uses WriteConsoleOutputW).
2. In a Warp pane, emit ESC[?1049h, then launch it with Lines/Columns set to the
   pane's exact grid size. Arrow down past the bottom of the file list — only the
   bottom row updates.
3. Repeat with Columns one less than the pane width. Scrolling now renders, but the
   pane flickers.
4. Run the same thing in a Windows Terminal pane — both work correctly.

To reproduce

(optional step) Download The full screen app: fcw: https://silk.apana.org.au/fc2development.php

Reproduction:
Affects full-screen console apps that use the classic Win32 Console API (WriteConsoleOutputW, ScrollConsoleScreenBuffer) rather than VT sequences. Repro needs no third-party software.

1. Save the script below as warp-repro.ps1.
2. Open a Warp pane running PowerShell and run it with $Inset = 0 (as written).
   Expected: the numbered lines march upwards each frame.
   Actual: every row stays frozen except the bottom one, where only the NEW nnn line changes. The ScrollConsoleScreenBuffer call succeeds; its effect is never rendered.
3. Edit line 1 to $Inset = 1 — so the console is sized one column narrower than the pane — and run it again.
   Actual: the lines now scroll correctly, but the pane flickers continuously.
4. Run both variants in a Windows Terminal pane on the same machine.
   Actual: both render correctly, no flicker.

So scrolling only renders when the app's console size differs from the pane grid (i.e. when it actually resizes the console), and that same resize is what flickers. There's no setting that gives both. Since Windows Terminal handles both cases over the same ConPTY, this looks like Warp's renderer rather than ConPTY.

The script mirrors what such an app does: switch to the alternate screen, size the console once at startup, paint a full screen, then scroll a region and write one new row at the bottom.

$Inset = 0 # run once with 0, then again with 1
Add-Type -Namespace R -Name C -MemberDefinition @'
[StructLayout(LayoutKind.Sequential)] public struct COORD { public short X, Y; }
[StructLayout(LayoutKind.Sequential)] public struct SMALL_RECT { public short Left, Top, Right, Bottom; }
[StructLayout(LayoutKind.Explicit)] public struct CHAR_INFO {
[FieldOffset(0)] public char UnicodeChar; [FieldOffset(2)] public ushort Attributes; }
[DllImport("kernel32.dll")] public static extern IntPtr GetStdHandle(int n);
[DllImport("kernel32.dll", CharSet=CharSet.Unicode)] public static extern bool ScrollConsoleScreenBufferW(
IntPtr h, ref SMALL_RECT s, IntPtr clip, COORD d, ref CHAR_INFO f);
'@
$ESC = [char]27; $h = [R.C]::GetStdHandle(-11)
[Console]::Write("$ESC[?1049h"); Start-Sleep -Milliseconds 400
try {
$rows = [Console]::WindowHeight; $cols = [Console]::WindowWidth - $Inset
try { [Console]::SetBufferSize($cols, $rows) } catch { }
$top = 1; $bottom = $rows - 2
for ($i = $top; $i -le $bottom; $i++) {
[Console]::SetCursorPosition(0, $i)
[Console]::Write(("line {0:d3} " -f $i) + ('-' * [Math]::Max(0, $cols - 12)))
}
for ($f = 1; $f -le 25; $f++) {
$r = New-Object R.C+SMALL_RECT
$r.Left = 0; $r.Top = [short]($top + 1); $r.Right = [short]($cols - 1); $r.Bottom = [short]$bottom
$d = New-Object R.C+COORD; $d.X = 0; $d.Y = [short]$top
$fi = New-Object R.C+CHAR_INFO; $fi.UnicodeChar = ' '; $fi.Attributes = 7
[void][R.C]::ScrollConsoleScreenBufferW($h, [ref]$r, [IntPtr]::Zero, $d, [ref]$fi)
[Console]::SetCursorPosition(0, $bottom)
[Console]::Write(("NEW {0:d3} " -f $f) + ('=' * [Math]::Max(0, $cols - 12)))
Start-Sleep -Milliseconds 250
}
} finally { [Console]::Write("$ESC[?1049l$ESC[?25h") }

Separately: PageUp/PageDown never reach a running full-screen app — they're consumed by Warp's input editor. Setting terminal:scroll_up_one_page and terminal:scroll_down_one_page to none in keybindings.yaml doesn't release them. Arrow keys are delivered normally.

Expected behavior

No response

Screenshots, videos, and logs

No response

Operating system (OS)

Windows

Operating system and version

Win 11 Business, Version 10.0.22631 Build 22631

Shell Version

PowerShell 7.6.3

Current Warp version

v0.2026.08.12.21.54.stable_00

Regression

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

Recent working Warp date

2026/08/19

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

[warp-for-oss]

@malizd

Here's what I found while triaging this issue:

Thanks for the detailed Windows repro. This is actionable as a Windows terminal-emulation/input bug, and the self-contained script is enough for initial routing without additional reporter details.

Maintainer details

I concluded that windows legacy Win32 Console API full-screen apps over ConPTY appear to expose a Warp terminal rendering/input bug where region scrolls require a resize that then causes flicker, and PageUp/PageDown are not reliably forwarded to the app..

Initial triage

This is a well-specified Windows terminal-emulation bug report. The core observed behavior is that a legacy Win32 console app using WriteConsoleOutputW / ScrollConsoleScreenBufferW does not visually scroll a region when its configured size exactly matches the Warp pane grid, but scrolling starts working after the app causes a console resize; that same resize path then produces continuous flicker. The separate PageUp/PageDown report should be tracked under terminal input because the keys are expected to be forwarded to a running full-screen app.

Reproducibility: High. The issue includes Warp version v0.2026.08.12.21.54.stable_00, Windows 11 build 22631, PowerShell 7.6.3, a self-contained PowerShell repro using ScrollConsoleScreenBufferW, and a Windows Terminal comparison on the same machine. I could not run the Windows-only repro from this Linux triage environment, but the provided evidence is specific enough to route without more reporter input.

Likely affected areas: Windows ConPTY handling, terminal-model/grid synchronization, alt-screen sizing, and terminal input forwarding. Code inspection shows Windows PTYs are created/resized through ConPTY (CreatePseudoConsole / ResizePseudoConsole), terminal output is parsed through Warp's ANSI/reset-grid path, and entering alt screen can trigger refresh_size() plus redundant ConPTY resizes when custom alt-screen padding is active. That combination is consistent with a scroll update only becoming visible after a resize and with resize-related flicker. The PageUp/PageDown path likely needs a separate check of the input/editor/keybinding routing because Warp defines editable terminal scroll bindings and forwards PageUp/PageDown to the PTY only when the terminal view considers the command long-running.

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

Powered by Oz