Mouse Input Spam / SIGPWR Signal Storm in WSL2

[wilfchun]

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

1. Install opencode 1.0.20 on NixOS running in WSL2
2. Run opencode in any directory
3. 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:

1. Line 60 in strace shows mouse tracking being enabled: \33[?1000h\33[?1002h\33[?1003h
2. Immediately after, SIGPWR signals start flooding
3. The process sends signals to itself (same PID: 380205)
4. 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:

1. A bug in the Bun runtime's signal handling on WSL2
2. An issue with opencode's async/threading implementation
3. A WSL2-specific interaction with the TUI library used

Workarounds Attempted

None of these resolved the issue:

• Setting trap "" PWR to block SIGPWR
• Changing TERM to different values
• Disabling mouse tracking escape sequences
• Running with setsid
• Using different terminal emulators

Related Issues

• #5046 - Mouse selection issues in Windows Terminal
• #3081 - Paste issues in WSL
• #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.

[github-actions[bot]]

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

• #5046: Can't copy text from opencode through mouse selection in Windows Terminal (similar WSL/mouse interaction issues)
• #3081: I can't paste text with CTRL+V or right mouse click when running inside WSL (other WSL mouse-related problems)
• #4012: Rendering problems inside pycharm on Windows (WSL/Debian) (other WSL rendering/display issues)
• #811: Text rendering is VERY slow (and CPU usage is really high even when idle) (high CPU usage and TUI responsiveness issues)

The common thread appears to be WSL-specific TUI/input handling issues that emerged after the opentui migration. Feel free to ignore if your SIGPWR signal spam issue is distinct from these.