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

Originally created by @alhnesn on GitHub (Dec 11, 2025).

Originally assigned to: @kommander on GitHub.

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

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

Originally created by @alhnesn on GitHub (Dec 11, 2025). Originally assigned to: @kommander on GitHub. ### 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

yindo added the opentui bug labels 2026-02-16 17:40:12 -05:00

yindo commented

@github-actions[bot] commented on GitHub (Dec 11, 2025):

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.

@github-actions[bot] commented on GitHub (Dec 11, 2025): 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.

yindo commented

@rekram1-node commented on GitHub (Dec 11, 2025):

@kommander maybe related to ur changes?

@rekram1-node commented on GitHub (Dec 11, 2025): @kommander maybe related to ur changes?

yindo commented

@kommander commented on GitHub (Dec 11, 2025):

I'll check

@kommander commented on GitHub (Dec 11, 2025): I'll check

yindo commented

@kommander commented on GitHub (Dec 12, 2025):

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

@kommander commented on GitHub (Dec 12, 2025): @alhnesn are you on windows 10 by any chance? I can't reproduce reliably on win11.

yindo commented

@simanga-dev commented on GitHub (Dec 12, 2025):

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 commented on GitHub (Dec 12, 2025): 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

yindo commented

@simanga-dev commented on GitHub (Dec 12, 2025):

~ ❯ opencode -v
1.0.150

@simanga-dev commented on GitHub (Dec 12, 2025): ``` ~ ❯ opencode -v 1.0.150 ```

yindo commented

@kommander commented on GitHub (Dec 12, 2025):

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.

@kommander commented on GitHub (Dec 12, 2025): 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.

yindo commented

@simanga-dev commented on GitHub (Dec 12, 2025):

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.

@simanga-dev commented on GitHub (Dec 12, 2025): 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.

yindo commented

@kommander commented on GitHub (Dec 12, 2025):

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

@kommander commented on GitHub (Dec 12, 2025): 1.0.127 works well? I am trying to dig through the commits but didn't find anything yet that could affect it really.

yindo commented

@CountElqyd commented on GitHub (Dec 12, 2025):

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.

@CountElqyd commented on GitHub (Dec 12, 2025): 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.

yindo commented

@simanga-dev commented on GitHub (Dec 12, 2025):

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.

@simanga-dev commented on GitHub (Dec 12, 2025): 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.

yindo commented

@alhnesn commented on GitHub (Dec 12, 2025):

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

@alhnesn commented on GitHub (Dec 12, 2025): > [@alhnesn](https://github.com/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.

yindo commented

@mqyang56 commented on GitHub (Dec 12, 2025):

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.

@mqyang56 commented on GitHub (Dec 12, 2025): 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.

yindo commented

@alhnesn commented on GitHub (Dec 13, 2025):

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

@alhnesn commented on GitHub (Dec 13, 2025): v1.0.152 did not show any improvements on me. It is the exact same for me.

yindo commented

@alhnesn commented on GitHub (Dec 16, 2025):

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.

@alhnesn commented on GitHub (Dec 16, 2025): **Update:** Found that **systemd triggers the issue**. Disabling systemd in WSL2 is a workaround that fixes the freezing. ### Workaround Edit `/etc/wsl.conf`: ```ini [boot] systemd=false ``` Then restart WSL from PowerShell: ```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.

yindo commented

@JohannesBertens commented on GitHub (Dec 19, 2025):

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

@JohannesBertens commented on GitHub (Dec 19, 2025): 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

yindo commented

@JRedeker commented on GitHub (Dec 20, 2025):

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.

@JRedeker commented on GitHub (Dec 20, 2025): 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.

yindo commented

@kommander commented on GitHub (Dec 20, 2025):

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

@kommander commented on GitHub (Dec 20, 2025): This `SIGPWR` issue might be related: [https://github.com/sst/opencode/issues/5168](https://github.com/sst/opencode/issues/5168)

yindo commented

@bezerra-lucas commented on GitHub (Dec 21, 2025):

@JRedeker u are a hero!

@bezerra-lucas commented on GitHub (Dec 21, 2025): @JRedeker u are a hero!

yindo commented

@Jay1 commented on GitHub (Dec 23, 2025):

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

@Jay1 commented on GitHub (Dec 23, 2025): > Experienced the same issue so I did a little digging -- the systemd clue was a good one [@alhnesn](https://github.com/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](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. 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

yindo commented

@cbaxley commented on GitHub (Jan 4, 2026):

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

@cbaxley commented on GitHub (Jan 4, 2026): > Experienced the same issue so I did a little digging -- the systemd clue was a good one [@alhnesn](https://github.com/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](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. 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: ```bash sudo mkdir -p /etc/systemd/timesyncd.conf.d sudo vim /etc/systemd/timesyncd.conf.d/poll-interval.conf ``` Add: ```ini [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: ```bash 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: ```ini [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

yindo commented

@imqqmi commented on GitHub (Jan 9, 2026):

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:

@imqqmi commented on GitHub (Jan 9, 2026): 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 1. 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. 2. 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. 3. Force kill and restart WSL # From PowerShell taskkill /f /im wslservice.exe wsl --shutdown wsl 4. Create/update .wslconfig Create %UserProfile%\.wslconfig with: [wsl2] memory=8GB swap=4GB localhostForwarding=true 5. 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: - https://github.com/microsoft/terminal/issues/17096 - https://github.com/microsoft/WSL/issues/10378 - https://github.com/docker/for-win/issues/14656

yindo commented

@HabeasPorpoise commented on GitHub (Jan 13, 2026):

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 :)

@HabeasPorpoise commented on GitHub (Jan 13, 2026): > > Experienced the same issue so I did a little digging -- the systemd clue was a good one [@alhnesn](https://github.com/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](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. > > 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 :)

yindo commented

@StevenTCramer commented on GitHub (Jan 14, 2026):

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.

@StevenTCramer commented on GitHub (Jan 14, 2026): ``` 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.

yindo commented

@pschiel commented on GitHub (Jan 22, 2026):

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

@pschiel commented on GitHub (Jan 22, 2026): 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

yindo commented

@ieiradouglas commented on GitHub (Jan 28, 2026):

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

@ieiradouglas commented on GitHub (Jan 28, 2026): As our friend said, running the command `sudo systemctl stop systemd-timesyncd` resolved the Opencode crashing problem.

yindo commented

@tontide1 commented on GitHub (Jan 29, 2026):

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

@tontide1 commented on GitHub (Jan 29, 2026): > **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

yindo commented