TUI freezes for ~10 seconds periodically on WSL2 (regression in v1.0.129)

[alhnesn]

Description

OpenCode TUI freezes for 2-10 seconds periodically while typing or scrolling on WSL2. Input is buffered during the freeze and appears after it resolves. The issue does not occur on native Windows.

Environment

Component	Details
OS	WSL2 Ubuntu 24.04 (kernel 6.6.87.2-microsoft-standard-WSL2)
OpenCode versions tested	1.0.128 (works), 1.0.129+ (freezes)
Terminals tested	Windows Terminal, WezTerm (both freeze)
Filesystem	Tested on both /mnt/c/ and native Linux filesystem (~/) - both freeze

Regression

Binary search identified the regression:

• 1.0.128: No freezing
• 1.0.129: Freezing starts

Relevant change in 1.0.129 changelog:

Bumped opentui to v0.1.55

What this is NOT

• Not SIGPWR spam (issue #5168) - no SIGPWR signals in strace
• Not 9P filesystem - freezes on native Linux filesystem too
• Not terminal-specific - happens on multiple terminals
• Not Bun-specific - also tested with npm installation, same issue

Steps to Reproduce

1. Install OpenCode v1.0.129+ on WSL2 Ubuntu
2. Run opencode in any directory
3. Type or scroll in the TUI
4. Observe periodic 2-10 second freezes

Workaround

Use version 1.0.128

OpenCode version

1.0.144 - 1.0.128

Steps to reproduce

1. Install OpenCode v1.0.129+ on WSL2 Ubuntu
2. Run opencode in any directory
3. Type or scroll in the TUI
4. Observe periodic 2-10 second freezes

Screenshot and/or share link

No response

Operating System

WSL Ubuntu 24.04

Terminal

Windows Terminal, Wezterm

[github-actions[bot]]

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

• #5130: Mac unresponsive, significant lag - Shows similar TUI freezing/responsiveness problems in opentui, with input and progress bar freezing
• #4239: TUI hangs when shell outputs massive log - Opentui-related hanging issue suggesting threading/event handling problems
• #3213: Bug: opencode run and TUI exits hang on v0.15+ - Earlier WSL2-specific hang/freeze regression with similar symptoms
• #5168: Mouse Input Spam / SIGPWR Signal Storm in WSL2 - WSL2-specific issue that could relate to input/event handling problems
• #2688: Opencode freezes when pressing option + left arrow key on MacBook - Keyboard input triggering TUI freezes with similar symptom patterns

Feel free to ignore if none of these address your specific case.

[rekram1-node]

@kommander maybe related to ur changes?

[kommander]

I'll check

[kommander]

@alhnesn are you on windows 10 by any chance? I can't reproduce reliably on win11.

[simanga-dev]

I am on windows 11, I was so scared to open a issue but I have been trying to find solution, tried deleted and all the installation method but the issue still exist

[simanga-dev]

~ ❯ opencode -v
1.0.150

[kommander]

No need to be scared. I heard of similar issues on win10 that's why I ask. I am trying to debug, but can't really reproduce it on my system.

[simanga-dev]

In my case is worse... I just learned that I can disable auto update because the latest version is not usable... if the is something that you need specific to be able to debug the issue, I can assist.

[kommander]

1.0.127 works well? I am trying to dig through the commits but didn't find anything yet that could affect it really.

[CountElqyd]

I tested v1.0.127 on wsl2 ubuntu.. seems too work well too. Freezing issues for on wsl2 started on v1.0.129 and above.

[simanga-dev]

Similar behaviour > I tested v1.0.127 on wsl2 ubuntu.. seems too work well too. Freezing issues for on wsl2 started on v1.0.129 and above.

[alhnesn]

@alhnesn are you on windows 10 by any chance? I can't reproduce reliably on win11.

I am on Windows 11:

PS C:\Users\Alihan> wsl --version
WSL version: 2.6.2.0
Kernel version: 6.6.87.2-1
WSLg version: 1.0.71
MSRDC version: 1.2.6353
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.22631.6199

---

Also v1.0.127 works well and I am currently using v1.0.128 without any problems.

[mqyang56]

The issue persists in 1.0.150, is partially improved but still causes stuttering in 1.0.151, and is significantly improved in 1.0.152, with only occasional stuttering.

[alhnesn]

v1.0.152 did not show any improvements on me. It is the exact same for me.

[alhnesn]

Update: Found that systemd triggers the issue.

Disabling systemd in WSL2 is a workaround that fixes the freezing.

Workaround

Edit /etc/wsl.conf:

[boot]
systemd=false

Then restart WSL from PowerShell:

wsl --shutdown

Evidence

Scenario	Result
Main Ubuntu with systemd enabled	Freezes on v1.0.129+
Another WSL2 distro with systemd disabled	No freezing
Main Ubuntu with systemd disabled	No freezing

Also worth noting: when both distros are open simultaneously, the systemd-enabled distro causes the other distro to freeze as well.

[JohannesBertens]

Also having this!

wsl --version WSL version: 2.6.1.0 Kernel version: 6.6.87.2-1 WSLg version: 1.0.66 MSRDC version: 1.2.6353 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26100.1-240331-1435.ge-release Windows version: 10.0.26200.7462

opencode --version 1.0.169

[JRedeker]

Experienced the same issue so I did a little digging -- the systemd clue was a good one @alhnesn. I think it's specifically systemd-journald rotating logs and causing a freeze when systemd-timesyncd is doing clock adjustments. Something is going on with the WSL time sync, I can see in my local logs there's lots of instances of systemd-journald[50]: Time jumped backwards, rotating. that seem to align with the cadence of freezes in the opencode tui. Pretty much exactly this issue: https://github.com/microsoft/WSL/issues/11790

By running sudo systemctl stop systemd-timesyncd and then watching the systemd-journald logs, the journald rotations stopped... and so did the freezes in OpenCode.

I have no idea where this actually puts us in terms of a solution though outside of temporarily disabling timesyncd.

[kommander]

This SIGPWR issue might be related: https://github.com/sst/opencode/issues/5168

[bezerra-lucas]

@JRedeker u are a hero!

[Jay1]

Experienced the same issue so I did a little digging -- the systemd clue was a good one @alhnesn. I think it's specifically systemd-journald rotating logs and causing a freeze when systemd-timesyncd is doing clock adjustments. Something is going on with the WSL time sync, I can see in my local logs there's lots of instances of systemd-journald[50]: Time jumped backwards, rotating. that seem to align with the cadence of freezes in the opencode tui. Pretty much exactly this issue: microsoft/WSL#11790

By running sudo systemctl stop systemd-timesyncd and then watching the systemd-journald logs, the journald rotations stopped... and so did the freezes in OpenCode.

I have no idea where this actually puts us in terms of a solution though outside of temporarily disabling timesyncd.

In regard to this, and open to other viewpoints ofc.

I think temporarily disabling it = you’re swapping a 10-second freeze for an eventual outage. I would assume the journal no longer self-limits correctly, so log volume accumulates until the filesystem hits its ceiling (or performance degrades from sheer size).

I just wanted to add just a tiny bit more information if someone intended to disable it to get some work done on WSL (like me earlier researching this potential workaround). That's your tradeoff from the information I gathered online