anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 17:45:27 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 17:45:27 -05:00
Owner
Copy Link
Copy Source

Originally created by @git-qiaozq on GitHub (Jan 11, 2026).

Originally assigned to: @rekram1-node on GitHub.

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)

Originally created by @git-qiaozq on GitHub (Jan 11, 2026). Originally assigned to: @rekram1-node on GitHub. ### 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)
yindo added the windowsopentuiperf labels 2026-02-16 17:45:27 -05:00
yindo commented 2026-02-16 17:45:27 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 11, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #5361: TUI freezes for ~10 seconds periodically on WSL2 (regression in v1.0.129) - Similar WSL2 freezing and performance regression, though this one mentions periodic freezes while typing/scrolling
  • #6172: High CPU usage (100%+) during LLM streaming in long sessions due to O(n) text buffer rendering - Root cause analysis explaining why large output triggers lag through expensive O(n) text buffer rendering
  • #7240: Typing in the prompt input pauses echoing characters occasionally - Related input latency issue on WSL

The issue specifically mentions xterm.js-based terminals (VSCode/Cursor integrated terminal) vs Windows Terminal working fine. This strongly suggests the root cause is OpenTUI's rendering pipeline not being optimized for xterm.js.

Feel free to ignore if your specific case differs from these issues.

@github-actions[bot] commented on GitHub (Jan 11, 2026): This issue might be a duplicate of existing issues. Please check: - #5361: TUI freezes for ~10 seconds periodically on WSL2 (regression in v1.0.129) - Similar WSL2 freezing and performance regression, though this one mentions periodic freezes while typing/scrolling - #6172: High CPU usage (100%+) during LLM streaming in long sessions due to O(n) text buffer rendering - Root cause analysis explaining why large output triggers lag through expensive O(n) text buffer rendering - #7240: Typing in the prompt input pauses echoing characters occasionally - Related input latency issue on WSL The issue specifically mentions xterm.js-based terminals (VSCode/Cursor integrated terminal) vs Windows Terminal working fine. This strongly suggests the root cause is OpenTUI's rendering pipeline not being optimized for xterm.js. Feel free to ignore if your specific case differs from these issues.
yindo commented 2026-02-16 17:45:27 -05:00
Author
Owner
Copy Link
Copy Source

@git-qiaozq commented on GitHub (Jan 11, 2026):

Update: Tested with v1.0.128 - Issue Still Exists

I downgraded to OpenCode v1.0.128 (the version before the WSL2 freeze regression in #5361), but the scroll lag issue persists.

This confirms that:

  1. This issue is NOT the same as #5361 (WSL2 TUI freeze regression in v1.0.129+)
  2. The scroll lag in xterm.js-based terminals (VSCode/Cursor) is a separate, longer-standing issue
  3. The root cause is likely the O(n) rendering complexity mentioned in #6172, which affects xterm.js terminals more severely than native terminals like Windows Terminal

Test Results

Version Scroll Lag in Cursor/VSCode Scroll in Windows Terminal
1.1.13 ❌ Severe lag (unusable) ✅ Normal
1.0.128 ❌ Severe lag (still exists) ✅ Normal

This suggests the performance issue with xterm.js-based integrated terminals has existed for a while and is independent of the v1.0.129 opentui update.

@git-qiaozq commented on GitHub (Jan 11, 2026): ### Update: Tested with v1.0.128 - Issue Still Exists I downgraded to OpenCode v1.0.128 (the version before the WSL2 freeze regression in #5361), but **the scroll lag issue persists**. This confirms that: 1. This issue is **NOT the same as #5361** (WSL2 TUI freeze regression in v1.0.129+) 2. The scroll lag in xterm.js-based terminals (VSCode/Cursor) is a **separate, longer-standing issue** 3. The root cause is likely the O(n) rendering complexity mentioned in #6172, which affects xterm.js terminals more severely than native terminals like Windows Terminal ### Test Results | Version | Scroll Lag in Cursor/VSCode | Scroll in Windows Terminal | |---------|-----------------------------|-----------------------------| | 1.1.13 | ❌ Severe lag (unusable) | ✅ Normal | | 1.0.128 | ❌ Severe lag (still exists) | ✅ Normal | This suggests the performance issue with xterm.js-based integrated terminals has existed for a while and is independent of the v1.0.129 opentui update.
yindo commented 2026-02-16 17:45:27 -05:00
Author
Owner
Copy Link
Copy Source

@hieudtr8 commented on GitHub (Jan 20, 2026):

Got same issues on Windows 10 with Cursor/Vscode IDE

@hieudtr8 commented on GitHub (Jan 20, 2026): Got same issues on Windows 10 with Cursor/Vscode IDE
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label opentui perf windows
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4794
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?