Repository navigation
Spamming OSC 52 copy freezes the application #20210
Description
Windows Terminal version
1.24.10921.0
Windows build number
10.0.26200.0
Other Software
No response
Steps to reproduce
- Run the powershell script:
$esc = [char]27
for ($i = 1; $i -le 200; $i++) {
$text = "copy-$i"
$b64 = [Convert]::ToBase64String(
[Text.Encoding]::UTF8.GetBytes($text)
)
$seq = "${esc}]52;c;${b64}${esc}\"
[Console]::Out.Write($seq)
[Console]::Out.Flush()
Start-Sleep -Milliseconds 20
}Or the bash command in WSL:
for i in $(seq 1 200); do printf '\033]52;c;%s\033\\' "$(printf "copy-%d" "$i" | base64 -w0)"; sleep 0.02; done- Click around the terminal a couple of times while it's running. The application freezes.
Expected Behavior
The application should still respond normally.
Actual Behavior
The application freezes (shows (Not Responding) on the window title).
Also freezes in 1.25.260427001-preview
I tried a few older releases. Doesn't freeze in 1.23.260121001.
Reacted by Matthew Murray, Jecvay Liu and Stepan Usatiuk
Activity
DHowett commentedon May 11, 2026
This may be true, but... also... don't do that? 🙂
evanlin96069 commentedon May 11, 2026
I noticed the issue when using text editors that has OSC 52 copy (like in Microsoft Edit). Sometimes it freezes even when the copy isn't that rapid. The script is just a more consistent way I found to reproduce the issue.
DHowett commentedon May 13, 2026
If I had to guess, it's waiting to open the clipboard. Anyway, we've got a repro. Thanks!
DHowett commentedon May 13, 2026
Leonard says "we can fix this by not holding the ticket lock while operating on the clipboard, and by coalescing repeated events"
murrayma-intel commentedon May 21, 2026
I have also been hitting this issue in normal usage over the past few weeks. I use Neovim and Tmux on a Linux system over an SSH session, configured to forward every copy to the host system clipboard through OSC-52. I'd say about ~5-10% of all copies cause the terminal to fully freeze for ~5 seconds. And every time you delete text in Neovim, it automatically copies that text to the clipboard, which causes this to trigger very frequently.
At first I thought it was an issue on the remote Linux system - it took me a while to realize it was actually the terminal itself that was freezing.
murrayma-intel commentedon May 21, 2026
Just downgraded to 1.23.260121001 and I can confirm the issue is not present in that version. However, this is a work PC, and corporate IT policy won't let me disable Microsoft Store app updates, so I cannot keep the downgraded version installed.
I'll just say that I very much look forward to this getting fixed.
zhiganov commentedon Jul 13, 2026
Version data point: I'm on 1.24.11321.0 / build 26200, and I hit a hard freeze (window chrome unresponsive, must
taskkill /IM WindowsTerminal.exe /F) when 3+ CLI agents stream heavy output to fullscreen TUIs and I click to switch tabs during the flood. That matches the "sustained escape-sequence output + clicking around the terminal" shape here, and lines up with your note that this regressed in 1.24 (clean on 1.23).Caveat: I haven't instrumented exactly which sequences my TUIs emit, so I can't confirm it's specifically OSC 52 in my case — flagging this as an adjacent heavy-output repro on the same regressed version rather than a confirmed OSC 52 repro.
wtdcode commentedon Oct 17, 2026
This is quite annoying for running coding agents in Windows Terminal.
lhecker commentedon Oct 19, 2026
Oh, good news! This was fixed by #20728. Please upgrade to the latest release (manually, if needed). 😊
wtdcode commentedon Oct 19, 2026
Tried Window Terminal Preview 1.26.2734.0 from Windows Store and it does not work =/. May I known the version containing the fix?
lhecker commentedon Oct 19, 2026
lazymio (@wtdcode) I was referring to the repro steps by the original issue submitter. If you have a different (albeit similar) issue, can you please find new repro steps? Otherwise, I would not be able to begin investigating and fixing the issue on my machine.
wtdcode commentedon Oct 19, 2026
On the Windows Terminal I can reproduce it this way:
tmux new -s testing/tui fullscreenenabled) and do not send anything.I know this is not a perfect reproduction and I'm asking my Claude to debug it on its own. A key observation is that, it works fine without
tmux.wtdcode commentedon Oct 19, 2026
Oh Claude finds it out: once I quit all old stable Windows Terminal windows and only leave the preview version, it no longer freezes in any cases. Claude says it also relates to my tmux
after-load-bufferhooks, which broadcasts keys to all clients, including both stable and preview WT, and cause further locks.Thanks for your efforts, and I finally got rid of this issue =p.
lhecker commentedon Oct 19, 2026
I'm really glad to hear it works for you!
wtdcode commentedon Oct 19, 2026
Unfortunately, I found a new reproduction due to a deadlock, without tmux and Claude code. Will soon send another issue.
wtdcode commentedon Oct 19, 2026
Here you go =p. #20819
I attached a reproduction without claude code and tmux. Let me know if you need more information.