You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Screen lag/freezing when typing text (WSL2, TMUX, Alacritty) #8484
I have recently started using opencode and I think it's a great tool, but unfortunately, when writing prompts, I experience unpleasant freeze/lags for few seconds. I use opencode inside WSL 2 on Windows 11, using the alacritty terminal inside tmux, although I checked and tmux has nothing to do with it here, I use bash.
I did not observe anything like that during the work of agent itself.
The GIF shows an unpleasant lag that disturbs with writing longer prompts and is simply annoying. Has anyone experienced something similar or knows how to fix it?
Same for me, WSL2, Wezterm/Windows Terminal. It also started happening sometime after 1.0 release. My freezes are actually 10 seconds or more, completely unusable. Works on a different machine with the same setup 🤷♂️
Reacted by Hank Patton, matevszm, Alex Copero, Helge, Bahram Hodjaev, Daniel Schreiber, Mohamed Farhan, mechanicalgux, Guillermo Fernández and YanXin Li
This is happening to me as of yesterday as well. It's immensely frustrating. It also applies to scrolling through the opencode window, not just typing. I am also using Ubuntu via WSL.
Reacted by matevszm, Martin Wernstål, Helge, Bahram Hodjaev, mechanicalgux and Guillermo Fernández
I’ve run into this issue multiple times on WSL2. These are the fixes that consistently worked for me.
Cleaning up the disk, making sure that there is free space available
Ensure system time is correctly synced
If your Windows system clock is out of sync (for example, 1 hour ahead due to DST or time sync issues), opencode can appear to freeze.
Internally, opencode uses time-based waits (e.g. CLOCK_REALTIME). When the system clock jumps or is incorrect, these waits can behave incorrectly and cause the UI to stop.
If none of the above worked, try to see the logs with strace:
sudo apt install -y strace
Run opencode until it freezes
Open a new terminal
Find the PID: pgrep -n opencode
Attach strace: sudo strace -p -f -s 200
If you see repeated futex(...) and sched_yield() calls (especially with FUTEX_CLOCK_REALTIME), it’s likely a time-sync or event-loop issue.
These lags occur when you have systemd-timesyncd enabled.
What happens is that WSL will adjust the time differently than Windows, and Hyper-V correcting time back into the past - which causes corrupt timestamps, freezes in the client, as Javascript timeouts will suddenly wait seconds.
These lags occur when you have systemd-timesyncd enabled.
What happens is that WSL will adjust the time differently than Windows, and Hyper-V correcting time back into the past - which causes corrupt timestamps, freezes in the client, as Javascript timeouts will suddenly wait seconds.
These lags occur when you have systemd-timesyncd enabled.
What happens is that WSL will adjust the time differently than Windows, and Hyper-V correcting time back into the past - which causes corrupt timestamps, freezes in the client, as Javascript timeouts will suddenly wait seconds.
Same for me, WSL2, Wezterm/Windows Terminal. It also started happening sometime after 1.0 release. My freezes are actually 10 seconds or more, completely unusable. Works on a different machine with the same setup 🤷♂️
Update:
the root cause in my case was that the Windows time service decided to stop working at some point and my clock had drifted 30 seconds into the future 🚀🚀🚀
after failing to fix the broken, just installed NetTime.
Activity
github-actions commentedon Jan 14, 2026
This issue might be a duplicate of an existing issue. Please check:
Feel free to ignore if your issue is specific to input/typing lag rather than general scrolling/rendering lag.
xxzefgh commentedon Jan 15, 2026
Same for me, WSL2, Wezterm/Windows Terminal. It also started happening sometime after 1.0 release. My freezes are actually 10 seconds or more, completely unusable. Works on a different machine with the same setup 🤷♂️
pattonjh commentedon Jan 16, 2026
This is happening to me as of yesterday as well. It's immensely frustrating. It also applies to scrolling through the opencode window, not just typing. I am also using Ubuntu via WSL.
Tylopilus commentedon Jan 19, 2026
Can confirm. I have the same issue displayed in the video
shahabsalehi commentedon Jan 19, 2026
I’ve run into this issue multiple times on WSL2. These are the fixes that consistently worked for me.
Cleaning up the disk, making sure that there is free space available
Ensure system time is correctly synced
If your Windows system clock is out of sync (for example, 1 hour ahead due to DST or time sync issues), opencode can appear to freeze.
Internally, opencode uses time-based waits (e.g. CLOCK_REALTIME). When the system clock jumps or is incorrect, these waits can behave incorrectly and cause the UI to stop.
If none of the above worked, try to see the logs with strace:
sudo apt install -y strace
Run opencode until it freezes
Open a new terminal
Find the PID: pgrep -n opencode
Attach strace: sudo strace -p -f -s 200
If you see repeated futex(...) and sched_yield() calls (especially with FUTEX_CLOCK_REALTIME), it’s likely a time-sync or event-loop issue.
If you see other problems I guess gpt could help.
pschiel commentedon Jan 20, 2026
These lags occur when you have
systemd-timesyncdenabled.What happens is that WSL will adjust the time differently than Windows, and Hyper-V correcting time back into the past - which causes corrupt timestamps, freezes in the client, as Javascript timeouts will suddenly wait seconds.
Try
sudo systemctl disable systemd-timesyncd && sudo systemctl stop systemd-timesyncdcaozhiyuan commentedon Jan 21, 2026
try disable animations and set env set OPENCODE_DISABLE_TERMINAL_TITLE=1 #8667 (comment) @matevszm
IPPO181 commentedon Jan 27, 2026
Thank you, this fixed my issue.
IshanArya commentedon Mar 17, 2026
Awesome, how did you figure this out?
xxzefgh commentedon Mar 18, 2026
Update:
the root cause in my case was that the Windows time service decided to stop working at some point and my clock had drifted 30 seconds into the future 🚀🚀🚀
after failing to fix the broken, just installed NetTime.
my clock is immaculate now.