Repository navigation
Automatic scrolling of window when setting cursor position #14774
Description
Windows Terminal version
1.16.230126001
Windows build number
10.0.19044.2486
Other Software
No response
Steps to reproduce
I mentioned this first in #14759.
You can reproduce the problem with this test program:
#include <windows.h>
int main()
{
HANDLE con = GetStdHandle(STD_OUTPUT_HANDLE);
CONSOLE_SCREEN_BUFFER_INFO csbi;
GetConsoleScreenBufferInfo(con, &csbi);
// use scrollback of 100 lines
COORD con_size = {
csbi.srWindow.Right - csbi.srWindow.Left + 1,
csbi.srWindow.Bottom - csbi.srWindow.Top + 1 + 100
};
SetConsoleScreenBufferSize(con, con_size);
// write 50 lines so the position is not at the top of the scrollback
for (int i = 0; i < 50; i++)
WriteConsoleA(con, "line\n", 5, NULL, NULL);
// stop at escape key
HANDLE in = GetStdHandle(STD_INPUT_HANDLE);
INPUT_RECORD ir;
DWORD didread;
while (ReadConsoleInput(in, &ir, 1, &didread))
{
if (ir.EventType == KEY_EVENT && ir.Event.KeyEvent.bKeyDown)
{
if (ir.Event.KeyEvent.wVirtualKeyCode == VK_ESCAPE)
break;
WriteConsoleA(con, &ir.Event.KeyEvent.uChar.AsciiChar, 1, NULL, NULL);
GetConsoleScreenBufferInfo(con, &csbi);
// re-set the cursor position where it already is, this is done
// so the cursor is visible at the new location after the character
// was printed
SetConsoleCursorPosition(con, csbi.dwCursorPosition);
// now the console window is scrolled so that the cursor is at the bottom
// of the window.
}
}
return 0;
}There is a difference of behavior when tried with either the conhost.exe of the current Win10, or the OpenConsole.exe of Microsoft.WindowsTerminal_Win10_1.16.10261.0_8wekyb3d8bbwe.msixbundle.
Between entering some keys, scroll the window up or down with the mouse.
Expected Behavior
Once you enter a key, and the cursor position is re-set, it will scroll the window to the cursor, but only if the cursor was not already in the visible part of the window.
Which is exactly how it works in conhost.exe.
Actual Behavior
But with OpenConsole.exe 1.16.230126001, the window is always scrolled so that the cursor is at the bottom of the screen, even if it was already visible before.
Activity
zadjii-msft commentedon Feb 2, 2023
Thanks for the repro!
j4james commentedon Feb 2, 2023
This change in behavior is almost certainly a result of PR #12972, and I suspect it could be difficult to resolve without reintroducing the virtual bottom bugs that PR was attempting to fix.
rforzachamp821 commentedon Jun 22, 2023
Thanks for putting this issue down. I have the same issue and it really sucks, as there's no other API that can perform the functions with GetConsoleScreenBufferInfo() in the meantime.
CONSOLE_SCREEN_BUFFER_INFO::dwCursorPosition.Y is also affected by this, and it maxes out at the vertical console window size when you hit the bottom of the console window to the point where the scrollbar shows up.
2 remaining items
Update README: document scroll stability limitation in long sessions
VoxCore84 commentedon Apr 1, 2026
This bug is the root cause of scroll-jump issues in all terminal applications that use the Ink rendering framework (React-based terminal UI for Node.js), which calls
SetConsoleCursorPositionon every render cycle.The most prominent affected application is Anthropic's Claude Code CLI, which has a large and growing Windows user base. Claude Code streams long-form output (code generation, file diffs, build results) while users need to scroll up to read prior context. Every render cycle triggers the viewport-snap-to-bottom described here, making it impossible to read scrollback during active output.
The practical impact across the Claude Code community:
snapOnOutput: false) — all attempting to work around this specificSetConsoleCursorPositionbehaviorsedpatch — but the underlying Windows Terminal behavior described here is the aggravating factor that makes the cursor repositioning scroll the viewport even inside synchronized update blocksThis affects any Ink-based application on Windows Terminal, not just Claude Code. Given that Ink is the standard framework for Node.js terminal UIs, the blast radius extends to the entire ecosystem of interactive CLI tools built with it.
feat(ui): 添加 Windows 终端动画控制以缓解 viewport 跳动问题
docs: research + design for fullscreen (scrollable virtualized transc…
feat(ui): Phase 1 - Synchronized Output (DEC 2026) for flicker-free r…
r800360 commentedon Jul 14, 2026
I would like to work on this.
I traced the current behavior to
ApiRoutines::SetConsoleCursorPositionImplinsrc/host/getset.cpp. After #12972, the function determines the snap position relative toGetVirtualViewport(), moves the real viewport, and callsUpdateBottom(), even when the cursor is already visible in the real viewport.My proposed boundary is:
GetViewport(), leave both the real viewport and virtual bottom unchanged.UpdateBottom()behavior.ScreenBufferTests::UpdateVirtualBottomWithSetConsoleCursorPositionwhere the real and virtual viewports differ but the real viewport already contains the cursor.I would also manually validate the reproducer here, #1222, #9754, and
clsbehavior so this does not undo the cases protected by #12972.Mike Griese (@zadjii-msft), does that behavioral boundary look correct before I open a draft PR?
j4james commentedon Jul 15, 2026
This doesn't sound right to me. The virtual bottom needs to be updated whenever the cursor is moved outside the virtual viewport boundaries. This can occur regardless of whether the cursor is inside the visible viewport or not.
It's also worth noting that this issue is specific to ConHost/OpenConsole as far as I'm aware. So if you're trying to address an issue in Windows Terminal, like the complaint from the Claude Code user above, I suspect that's unrelated to this code.
rforzachamp821 commentedon Jul 15, 2026
Yes. The real problem here is not that the Windows Terminal is doing it wrong, but it's that ConHost (conio.h) has been doing it wrong for so long.
GetConsoleScreenBufferInfo()traditionally returns the position of the cursor relative to the entire scrollbuffer. The current implementation in OpenConsole will result in the returnedCONSOLE_SCREEN_BUFFER_INFOobject to contain the cursor co-ordinates for the visible buffer/current viewport area only. This is correct, but if we were to get Microsoft to fixGet/SetConsoleCursorPosition()to properly address this, it would break other API functions (specifically functions in conio.h) and legacy applications which still use the logic of the old method.Hence, I think this should be fixed as a profile-specific setting implementation. A simple toggle should do the trick. Enable the old method of cursor position logic (default, off), enable the new method (on). When off, the cursor position would be updated based on the position on the entire scrollbuffer. When on, the cursor position would be updated based on the viewport and restricted to that area, just like it is now.
I believe this could work because an installation of Claude could just create a new profile on Windows Terminal sticking to the old method of console cursor position data. Then, the devs for those API tools can adapt their logic to the old method.
All this is provided Microsoft isn't willing to fix their cursor functions AND conhost.
DHowett commentedon Jul 15, 2026
I believe that to be a misapprehension of what that pull request does.
rforzachamp821 commentedon Jul 15, 2026
You are correct. It's been a while since i dug into this so I forgot all my PR numbers, LOL. Just axed it instead, edited.
fix: 老 conhost 精简模式写代码时画面左右跳与闪屏
fix(render): cursor 停靠从 frame 顶部反转为底部——对齐 CC ink，修 WT 视口回拉/input 消失
godot42x commentedon Aug 16, 2026
Almost all AI agent CLIs have this issue: while working, the user is reading the output, and then the entire screen gets offset and scrolls to the top.
DHowett commentedon Aug 16, 2026
Agentic CLIs by and large use the alternate screen buffer and implement their own scrolling. There is nothing we can do about that.