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

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 Mouse Input Spam / SIGPWR Signal Storm in WSL2 #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

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

Workaround

Use version 1.0.128

OpenCode version

1.0.144 - 1.0.128

Steps to reproduce

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

Screenshot and/or share link

No response

Operating System

WSL Ubuntu 24.04

Terminal

Windows Terminal, Wezterm

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

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

@kommander

@kommander maybe related to ur changes?

I'll check

@alhnesn

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

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

~ ❯ opencode -v
1.0.150

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.

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.

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

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.

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 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.

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.

The time syncing was broken on my WSL on windows 11 too. I disabled the service and told wsl to use windows to sync.

You can configure it to poll much less frequently rather than disabling it entirely (WSL2 time drift is a real problem if you leave it off too long):
Edit the config:

sudo mkdir -p /etc/systemd/timesyncd.conf.d
sudo vim /etc/systemd/timesyncd.conf.d/poll-interval.conf

Add:

[Time]
PollIntervalMinSec=3600
PollIntervalMaxSec=86400

This sets the minimum poll to 1 hour and max to 24 hours (defaults are 32 seconds min, 34 minutes max).
Then restart the service:

sudo systemctl restart systemd-timesyncd

Alternative approach — use Windows time instead:
Since WSL2 can sync from Windows, you can disable the service entirely and rely on Windows time sync. Add to /etc/wsl.conf:

[interop]
enabled = true

[boot]
systemd = true

Then just leave systemd-timesyncd disabled sudo systemctl disable systemd-timesyncd . Windows will keep the clock reasonable.
Check current status:
bashtimedatectl status
timedatectl timesync-status

I've asked claude opus for some tips, I've had the same issues with claude code so in my case it's not specific to OpenCode. I've disabled resource saver to see if that helps, but I'm going to continue tomorrow and see if that helped.

Most Likely Causes & Fixes

Docker Desktop (if installed)

This is a very common cause. Docker's Resource Saver mode conflicts with WSL 2.5.1+ (cgroupv2).

Fix: Disable Resource Saver in Docker Desktop:

Docker Desktop → Settings → Resources → Advanced → Disable "Resource Saver"

Or close Docker Desktop entirely to test if it's the cause.

Restart LxssManager Service

From Windows (Run as Admin PowerShell):
Restart-Service LxssManager
Or: Open services.msc → Find "LxssManager" → Restart it. Also set it to Automatic startup.

Force kill and restart WSL

From PowerShell

taskkill /f /im wslservice.exe
wsl --shutdown
wsl

Create/update .wslconfig

Create %UserProfile%.wslconfig with:
[wsl2]
memory=8GB
swap=4GB
localhostForwarding=true

Quick temporary fix when frozen

When it happens: Press Ctrl+C, then Ctrl+/- (zoom in/out) - this sometimes unsticks it.

Do you have Docker Desktop installed? That's the most common culprit for this exact symptom pattern.

Sources:

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.

The time syncing was broken on my WSL on windows 11 too. I disabled the service and told wsl to use windows to sync.

You can configure it to poll much less frequently rather than disabling it entirely (WSL2 time drift is a real problem if you leave it off too long): Edit the config:

sudo mkdir -p /etc/systemd/timesyncd.conf.d
sudo vim /etc/systemd/timesyncd.conf.d/poll-interval.conf
Add:

[Time]
PollIntervalMinSec=3600
PollIntervalMaxSec=86400
This sets the minimum poll to 1 hour and max to 24 hours (defaults are 32 seconds min, 34 minutes max). Then restart the service:

sudo systemctl restart systemd-timesyncd
Alternative approach — use Windows time instead: Since WSL2 can sync from Windows, you can disable the service entirely and rely on Windows time sync. Add to /etc/wsl.conf:

[interop]
enabled = true

[boot]
systemd = true
Then just leave systemd-timesyncd disabled sudo systemctl disable systemd-timesyncd . Windows will keep the clock reasonable. Check current status: bashtimedatectl status timedatectl timesync-status

Completely cured the annoying freezing in Windows 10 22H2 WSL2 Ubuntu 22/24 Opencode v1.1.15 for me. At first I thought it was some agents that I had loused up with the opencode.json but quickly realized it was more than that. How were the dots connected between systemd-timesyncd and this weird issue is what I am dying to know, that is next level troubleshooting I realize :)

sudo systemctl stop systemd-timesyncd
sudo systemctl disable systemd-timesyncd

did the trick for me. Opus assures me that this is ok to leave disabled.

systemd-timesyncd MUST be disabled under WSL, this is a fault in the distribution to have it enabled by default (standard Linux behaviour). timesyncd is battling constantly vs HyperV timesync (which is the correct and intended mechanic)

Reason:

when using WSL, HyperV does the timesync with the host
when timesyncd is active, it will sync the time different than the Windows host does, result: time is slightly ahead
this causes HyperV to hard reset the time back a few seconds into the past
result: timestamps are corrupted for a short time
JS apps like opencode will freeze due to timeout handling

example:

App is waiting for next frame, e.g. "now +100ms"
HyperV resets the time backwards -> suddenly the "now" is a e.g. lets say 3 seconds in the past
a 100ms wait turns into 3100ms -> app freezes

As our friend said, running the command sudo systemctl stop systemd-timesyncd resolved the Opencode crashing problem.

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.

thank you sir ! you helped me a lot

I'm having a similar problem, but it only occurs when I open a project folder where I've previously used OpenCode (running opencode with no response from the terminal). In all other scenarios, OpenCode runs fine. I'm not sure what the issue is; I've tried various fixes for similar problems, but my situation seems to be different. Would anyone have any insights to why this happens?

WSL version: 2.6.1.0
Kernel version: 6.6.87.2-1
WSLg version: 1.0.66
Windows version: 10.0.26100.7840
Open code 1.1.60

Opened upstream tracking issue in OpenTUI for the WSL frame-stall root cause: anomalyco/opentui#775. The proposed fix is to use monotonic timing (performance.now) and immediate-based deadline scheduling in renderer frame timing.

I’m also seeing this when running OpenCode inside WSL on Windows.

The main symptom on my side is that the input box becomes unresponsive or noticeably delayed while typing. Sometimes keystrokes do not appear immediately and then show up after a pause, which makes the interface feel unreliable for normal use.

From the user side, this feels less like a model/network problem and more like the TUI/input layer is intermittently freezing or buffering input in WSL.

If helpful, I can also provide more environment details (OpenCode version, WSL distro/version, terminal app, and whether it reproduces consistently).

I originally thought that this bug only impacted the OpenTUI interface.
But from my testing OpenCode web is also impacted.
Response times for simple prompts that would typically take seconds, often take minutes.
I haven't fully confirmed this, but it seemed like it was wasting tokens with more requests.
It could be dangerous, even if you were on the cusp, as you would likely not even notice you are spending x% more unneeded tokens.

The fix provided above fixed OpenCode web for me.
#5361 (comment)

It is also worth noting that if anomalyco/opentui#775 made it into release, it did not fix the issue.
The last version I tested on was v1.3.8.

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

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

Description

Environment

Regression

What this is NOT

Steps to Reproduce

Workaround

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

8 remaining items

From PowerShell

Workaround

Evidence

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Description

Environment

Regression

What this is NOT

Steps to Reproduce

Workaround

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on Dec 11, 2025

rekram1-node commented on Dec 11, 2025

kommander commented on Dec 11, 2025

kommander commented on Dec 12, 2025

simanga-dev commented on Dec 12, 2025

simanga-dev commented on Dec 12, 2025

kommander commented on Dec 12, 2025

simanga-dev commented on Dec 12, 2025

kommander commented on Dec 12, 2025

CountElqyd commented on Dec 12, 2025

simanga-dev commented on Dec 12, 2025

alhnesn commented on Dec 12, 2025

8 remaining items

cbaxley commented on Jan 4, 2026

imqqmi commented on Jan 9, 2026

From PowerShell

HabeasPorpoise commented on Jan 14, 2026

StevenTCramer commented on Jan 14, 2026

pschiel commented on Jan 22, 2026

ieiradouglas commented on Jan 28, 2026

tontide1 commented on Jan 29, 2026

Workaround

Evidence

BruceManuelwayne commented on Feb 12, 2026

turazashvili commented on Mar 4, 2026

yongkang-yang commented on Mar 14, 2026

Warfront1 commented on Apr 2, 2026

github-actions commented on Jul 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions