Severe scroll lag in VSCode/Cursor integrated terminal on WSL2 after large output (unusable for minutes)

[git-qiaozq]

Description

OpenCode becomes completely unusable in VSCode/Cursor integrated terminal on WSL2 after outputting a moderate amount of content. Scrolling freezes for tens of seconds to several minutes, making the application practically unusable. However, running the same OpenCode version in Windows Terminal + WSL works perfectly.

Environment

Component	Version
OpenCode	1.1.13
OS	Windows 11
WSL	2.6.3
WSL Distro	Ubuntu 24.04.2 LTS
Cursor	2.3.34 (VSCode 1.105.1)
VSCode	1.105.1 (same issue)
Windows Terminal	Works normally

Steps to Reproduce

1. Open Cursor or VSCode on Windows 11
2. Connect to WSL2 environment
3. Run opencode in the integrated terminal
4. Ask a question that generates a long response
5. Try to scroll up/down during or after the output
6. Observe: scrolling becomes extremely laggy (tens of seconds to minutes of delay)

Additional reproduction path:

1. Use /session to restore a previous session
2. Scroll up and down a few times quickly
3. Observe: after a few scroll operations, the lag appears

Expected Behavior

Scrolling should be smooth and responsive, similar to the experience in Windows Terminal.

Actual Behavior

Scenario	Behavior
During LLM streaming	Almost impossible to scroll, UI freezes
After output completes	Scroll lag of 10-60+ seconds
After restoring session via /session	Initially OK, then severe lag after a few scroll operations
In Windows Terminal + WSL	✅ Works perfectly, no lag

Key Observation

The same OpenCode version (1.1.13) works perfectly when running through:

• PowerShell → wsl → opencode
• Windows Terminal → WSL → opencode

This strongly suggests the issue is specific to xterm.js-based integrated terminals (VSCode/Cursor) combined with OpenTUI's rendering on WSL2.

Likely Related Issues

Issue	Relevance
#5361	WSL2 TUI freeze regression (v1.0.129+) - similar root cause
#6172	O(n) text buffer rendering causing high CPU - explains why large output triggers lag
#7316	Mouse wheel stops working on Windows Terminal - possibly related input handling issue
#5168	SIGPWR signal storm in WSL2 - another WSL2-specific issue

Potentially Related PRs

These PRs appear to address the underlying performance issues:

• #3346 - Virtualize message rendering to remove O(n) reflows
• #2867 - Eliminate O(n) scans from render hot path

Workaround

Currently using Windows Terminal + WSL as a workaround, which works normally.

Additional Context

This issue makes OpenCode essentially unusable for daily development in Cursor/VSCode on WSL2, which is a very common development environment. The fact that Windows Terminal works fine suggests this is fixable with rendering optimizations for xterm.js-based terminals.

Would be happy to provide additional diagnostic information (strace, performance profiles, etc.) if needed.

OpenCode version

1.1.13

Operating System

Windows 11 + WSL2 2.6.3 + Ubuntu 24.04.2 LTS

Terminal

Cursor 2.3.34 / VSCode 1.105.1 integrated terminal (both affected)