Mouse Input Spam / SIGPWR Signal Storm in WSL2 #5168
Description
Mouse Input Spam / SIGPWR Signal Storm in WSL2
Description
When running opencode in NixOS on WSL2, the application becomes unusable due to continuous SIGPWR (power signal) spam. The application sends itself hundreds of SIGPWR signals per second, causing write operations to continuously restart and creating what appears as "mouse input spamming."
Environment
- OS: Linux nixos 6.6.87.2-microsoft-standard-WSL2
- WSL Version: 2.6.2.0
- Kernel: 6.6.87.2-1
- Terminal: xterm-256color
- OpenCode Version: 1.0.20
- Platform: NixOS on WSL2
Steps to Reproduce
- Install opencode 1.0.20 on NixOS running in WSL2
- Run
opencodein any directory - Observe the TUI becoming unresponsive with continuous signal spam
Expected Behavior
The opencode TUI should run normally with mouse tracking enabled, responding to user input without signal spam.
Actual Behavior
The application sends itself continuous SIGPWR signals, causing:
- Write operations to restart repeatedly (ERESTARTSYS)
- Mouse input appearing to spam
- The TUI becoming effectively unusable
- High CPU usage due to signal handling
Evidence from strace
Running strace -e signal,write opencode shows:
write(1, "\33[?2027h\33[?2004h\33[?1000h\33[?1002h\33[?1003h", 48) = 48
write(1, "\33[14t", 5) = 5
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=380205, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=380205, si_uid=1000} ---
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=380205, si_uid=1000} ---
[... hundreds more SIGPWR signals ...]
write(1, "5m\33[48;2;34;36;54m "..., 7274) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGPWR {si_signo=SIGPWR, si_code=SI_TKILL, si_pid=380205, si_uid=1000} ---
The key observations:
- Line 60 in strace shows mouse tracking being enabled:
\33[?1000h\33[?1002h\33[?1003h - Immediately after, SIGPWR signals start flooding
- The process sends signals to itself (same PID: 380205)
- Write operations repeatedly get ERESTARTSYS due to signal interruption
Analysis
The SIGPWR signals are being generated internally by the opencode process (SI_TKILL with same PID), suggesting this is either:
- A bug in the Bun runtime's signal handling on WSL2
- An issue with opencode's async/threading implementation
- A WSL2-specific interaction with the TUI library used
Workarounds Attempted
None of these resolved the issue:
- Setting
trap "" PWRto block SIGPWR - Changing TERM to different values
- Disabling mouse tracking escape sequences
- Running with
setsid - Using different terminal emulators
Related Issues
- Can't copy text from opencode through mouse selection in Windows Terminal #5046 - Mouse selection issues in Windows Terminal
- I can't paste text with CTRL+V or right mouse click when running inside WSL #3081 - Paste issues in WSL
- Rendring problems inside pycharm on Windows (WSL/Debian) #4012 - Rendering problems in WSL
However, none of these mention the SIGPWR signal spam specifically.
Additional Context
This appears to be WSL2-specific, as the issue does not occur on native Linux systems. The signal storm begins immediately after the TUI initializes mouse tracking, suggesting a correlation between mouse tracking and the signal handling bug.