Windows Terminal freezes all windows when one tab receives high‑rate stdout

[zoharl3]

Windows Terminal version

10.0.22631.6060

Windows build number

10.0.22631.6060

Other Software

No response

Steps to reproduce

1. Open Windows Terminal (PowerShell or CMD tab).

2. Run a program that produces continuous stdout updates.
   Example Python script (sleep reduced from 0.3 → 0.01 to emphasize the issue):

   import sys, os, time
   from pathlib import Path

   def tail_follow(path):
       last_size = 0
       last_mtime = 0
       while True:
           if not os.path.exists(path):
               os.system("cls")
               last_size = 0
               last_mtime = 0
               time.sleep(0.01)
               continue

           stat = os.stat(path)
           size = stat.st_size
           mtime = stat.st_mtime

           if size < last_size:
               os.system("cls")
               last_size = 0

           if mtime != last_mtime:
               with open(path, "rb") as f:
                   f.seek(last_size)
                   data = f.read()
                   print(data.decode("utf-8", errors="replace"), end="", flush=True)
               last_size = size
               last_mtime = mtime

           time.sleep(0.01)

   def main():
       if len(sys.argv) < 2:
           print("usage: tail.py <path>")
           sys.exit(1)
       tail_follow(sys.argv[1])

   if __name__ == "__main__":
       main()

3. While the script is running, open a new Windows Terminal window or tab.

Expected Behavior

Other Terminal windows/tabs should remain responsive.
New windows should render normally.

Actual Behavior

• New Terminal windows draw only a frame and then stop rendering.
• Existing Terminal windows freeze completely.
• The freeze persists until the high‑rate stdout process is stopped.

This does not occur in standalone cmd.exe (OpenConsole).
The issue appears specific to Windows Terminal’s renderer/UI thread.

Notes
This appears to be renderer starvation: one tab’s output load prevents the UI thread from servicing other windows.

Standalone CMD does not exhibit this behavior, suggesting the bottleneck is in Terminal’s rendering pipeline rather than OpenConsole.

[UfBt12qJNZKcw]

Calling os.system("cls") inside a 10ms loop constantly spawns subshells

[DHowett]

Thanks for the repro! Interesting to consider... I wonder if the issue is more related to quickly attaching processes (os.system("cls") runs cmd.exe /c cls, and doing that over and over is going to be at least a little overwhelming in any case) to the terminal rather than it quickly producing output.

If you replace os.system("cls") with emitting \e[H\e[2J\e[3J (you'll need to enable ENABLE_VIRTUAL_TERMINAL_PROCESSING or output mode flag 4) does it do anything for the issue?

I'm not suggesting this as a long-term fix, FWIW, for an issue on our side. You still may want to keep it because it will improve your performance and avoid spawning other processes regardless of what we do here.

(If it doesn't resolve the issue, I wonder if we're inundating the UI thread with scroll notifications.)

[zoharl3]

Thanks for the cls tip. However, while the monitoring is often, it is rarely triggered--it usually happens only when the file is recreated. The quick and dirty cls is enough for now, and I don't believe it's the cause for the issue. To be on the safe side, just remove this part of the code.

This is just a quick simple example. In general, I note apps, such as
https://github.com/CrypticSignal/better-ffmpeg-progress
that spam and freeze the terminal.