anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Mouse Input Spam / SIGPWR Signal Storm in WSL2 #3358

New Issue
Open
opened 2026-02-16 17:39:46 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 17:39:46 -05:00
Owner
Copy Link
Copy Source

Originally created by @wilfchun on GitHub (Dec 6, 2025).

Originally assigned to: @kommander on GitHub.

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.

Originally created by @wilfchun on GitHub (Dec 6, 2025). Originally assigned to: @kommander on GitHub. # 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.
yindo added the opentui label 2026-02-16 17:39:46 -05:00
yindo commented 2026-02-16 17:39:46 -05:00
Author
Owner
Copy Link
Copy Source

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

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.

@github-actions[bot] commented on GitHub (Dec 6, 2025): 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.
yindo commented 2026-02-16 17:39:46 -05:00
Author
Owner
Copy Link
Copy Source

@gagapony commented on GitHub (Jan 11, 2026):

I just used the official OpenCode flake.nix to build the app, and it works fine.
https://github.com/gagapony/nixosdots/commit/cfcbb641a22276555d8c11084b1482ac663d1de6

@gagapony commented on GitHub (Jan 11, 2026): I just used the official OpenCode flake.nix to build the app, and it works fine. https://github.com/gagapony/nixosdots/commit/cfcbb641a22276555d8c11084b1482ac663d1de6
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label opentui
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3358
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?