[Bug] 1.0.49 regression: TUI rendering lag inside tmux on mintty/Cygwin

[armandino]

Describe the bug

Summary

The TUI in copilot CLI 1.0.49 renders with severe lag (bursts then freezes, spinner stutter, "stuck until keypress") when run inside a tmux pane on Cygwin/Windows. Versions 1.0.43 and 1.0.48 do not have this problem. The regression seems to have been introduced in 1.0.49.

The problem disappears when copilot is run directly in mintty without tmux, so this is specific to copilot's interaction with tmux's pane render pipeline.

Environment

• Windows 11
• Cygwin 3.6.9 (mintty 3.8.2)
• tmux next-3.4 (Cygwin package, ~Jan 2024 snapshot of post-3.3a)
• Also reproduces on tmux 3.6b built from upstream

Reproduction

1. From a Cygwin mintty inside a tmux session, launch copilot:
2. Send a couple of prompts that produce streaming output (e.g. "list 1 to 100, one per line").
3. Observe: output arrives in bursts, the spinner stutters, the cursor occasionally freezes until a keypress.

Bisection result

Same machine, same tmux pane, same prompt:

Version	Behavior
1.0.43	smooth
1.0.48	smooth
1.0.49	laggy (all symptoms above)

Byte-stream analysis

Captured copilot's pty output via tmux pipe-pane -O while it produced ~30KB over ~7 seconds:

• 232 distinct chunks; mean chunk size 116 bytes; chunk-rate ~31/sec
• 87 BSU/ESU pairs (ESC[?2026h ... ESC[?2026l) emitted — but all 87 are empty: zero bytes between the BSU and the matching ESU. Confirmed by regex extraction:

  unique sync frame contents: 1   (the empty bytestring b'')
  

• The actual screen-update content (cursor movements, color codes, text) arrives in separate, unwrapped chunks afterward, with inter-chunk gaps up to 226ms (p95: 102ms).

In other words: copilot announces a synchronized update (BSU then ESU immediately), then writes the real frame content in subsequent unframed chunks. Tmux faithfully renders each unframed chunk independently. The mode-2026 sync mechanism is being emitted but is not actually wrapping any content.

For comparison, equivalent bash and PowerShell output through the same tmux pane is smooth. Those producers send append-only line-oriented output and don't trigger this rendering pattern.

Workaround

Downgrade to 1.0.48

Affected version

No response

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response

[maaslalani]

Hi @armandino, can you please try https://github.com/github/copilot-cli/releases/tag/v1.0.51 and tell us if this issue is still occuring? We fixed an issue for WSL that sounds like this.

Thank you!

[dscho]

@maaslalani I still see exactly this issue even in v1.0.51. Symptom: the status at the bottom starts as usual, with that sort of "flash" being rendered in this sort of busy animation, and then it simply stops. That's when a permission request was supposed to appear. But it is not shown. And when I run it through winpty.exe, it does appear, it's just that the rendering is really choppy then because it has to shuffle bytes back and forth between an emulated Console and the actual pty.

And I totally agree, the issue appeared with v1.0.49.

[dscho]

Oh, also please note that this has nothing to do with WSL at all.