[Windows] Hard-killed TUI leaves mouse reporting enabled; next launch does not reset terminal state #18901

Activity

1. github-actions

   assigned

   kommander

   on Mar 24, 2026
2. github-actions

   added

   opentuiThis relates to changes in v1.0, now that opencode uses opentuiThis relates to changes in v1.0, now that opencode uses opentui

   windows

   on Mar 24, 2026
3. github-actions commented on Mar 24, 2026

   

   github-actionsBot

   on Mar 24, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • After closing the OpenCode CLI, scrolling the mouse wheel and moving the mouse in the powershell will cause garbled characters. #11748: Same symptom on Windows - mouse movement/scrolling causes garbled characters after closing OpenCode CLI in PowerShell
   • In version 1.1.23, the issue of the mouse wheel triggering abnormal ASCII codes after exiting reappeared. #8908: Same symptom on Windows 11 - mouse wheel triggers abnormal ASCII codes after exiting via Ctrl+C
   • bug: exiting tui on windows has improper exit sequence handling #5070: Windows TUI exit leaves mouse escape sequences in terminal (git bash)

   Note: The author already distinguishes this from #13301 (Ctrl+C) — the key difference here is taskkill /F with no exit handlers. If the underlying fix is the same (reset mouse tracking on startup), these may still be related enough to consolidate.
4. kommander commented on Apr 12, 2026

   

   kommander

   on Apr 12, 2026 – with Linear

   Contributor

   More actions

   There is nothing any app that activates mouse can do when killed like that, same would happen for lazygit for example.
5. kommander

   closed this as not plannedon Apr 12, 2026
6. MrCorsario commented on Jun 16, 2026

   

   MrCorsario

   on Jun 16, 2026

   Last edited by MrCorsario

   More actions

   Same symptom, different trigger — not just force-kill.

   This also happens during startup if MCP server connections block TUI initialization.

   Setup:

   • Linux (Fedora 44 / Bazzite), xterm-256color
   • opencode v1.17.7
   • MCP server configured in opencode.jsonc with "type": "remote" and "timeout": 30000
   • The server was unreachable (wrong URL/auth at the time)

   What happens:
   On launch, opencode enables mouse tracking (\x1b[?1003h, \x1b[?1006h) but then blocks trying to connect to the MCP server. During the 30s timeout window, any mouse movement floods the terminal with raw SGR sequences like [<35;116;3M. The TUI hasn't finished initializing its input handler yet, so events go unhandled and get echoed.

   Once the MCP connection times out, the TUI completes init and works normally. But the window between "mouse tracking ON" and "TUI ready to consume events" is unprotected.

   Root cause:
   Startup ordering problem — mouse tracking is enabled synchronously during init, but MCP connections are attempted inline (blocking the event loop). If they stall, mouse events arriving before the TUI's StdinParser is active leak as visible text.

   Recovery: Once MCP connects or times out, everything works normally. No terminal reset needed.

   Workaround: fix MCP connection.

   Relevance to #18901: Same mechanism — mouse events leaking because tracking is enabled without the TUI being ready to consume them. PR #18902 (reset mouse tracking on startup) would cover this case too. The fix should ensure \x1b[?1003l / \x1b[?1006l is sent before \x1b[?1003h / \x1b[?1006h, OR defer the enablement until after async connections settle.