terminal

This is a bug (issue #20846) in Windows Terminal 1.24 caused by the experimental repositionCursorWithMouse feature. When it's enabled together with autoMarkPrompts, clicking anywhere in a running program's output is treated as a cursor-reposition request, so Terminal injects one Left-arrow key event per cell between the cursor and the click point — potentially thousands of key events. Programs that read keyboard input one key at a time (e.g. ffmpeg polling for q) get flooded and stop responding to input. Workaround: disable the feature. Open Settings (Ctrl+,) → 'Open JSON file', and under profiles.defaults set "experimental.repositionCursorWithMouse": false (or remove the line, false is the default), then save. Until a fix ships, also avoid clicking on scrollback/output regions — only click on the command line currently being edited. A fix has been proposed (only reposition when the click is on the cursor's logical line, including wrapped rows) but is not yet released.

This is a confirmed regression in Windows Terminal 1.24 (build 1.24.10921.0) and 1.25 Preview (1.25.260427001). When a script floods the terminal with OSC 52 escape sequences (e.g., a PowerShell/bash loop emitting ESC]52;c;<base64>ESC\ every ~20ms), the UI thread locks up and the window shows '(Not Responding)' once you click it. Workaround: downgrade to Windows Terminal 1.23 (build 1.23.260121001 or earlier), where the freeze does not occur, until a fixed release ships. You can install the older version by downloading the 1.23 .msixbundle from the GitHub Releases page and installing it with Add-AppxPackage. Avoid running tools that emit high-frequency OSC 52 clipboard writes (e.g., tmux/nvim copy loops over SSH) on the affected versions.