bug: mouse escape sequences garbled after TUI exit

[agutmanstein-scale]

Description

After exiting the opencode TUI (via quit, Ctrl+C, or process stop), mouse escape sequences appear as garbled text in the terminal:

35;89;19M35;84;20M35;76;22M35;71;23M35;67;23M35;67;24M35;67;25M35...

This is a separate issue from in-session mouse garbling (#3199 / PR #19520). The in-session bug is about fragmented SGR sequences leaking through StdinParser timeouts during active use. This bug occurs after the TUI has exited.

Root Cause

This is an upstream bug in @opentui/core's cleanupBeforeDestroy() method. During renderer destruction, stdin.setRawMode(false) is called (re-enabling terminal ECHO) before mouse tracking is disabled. Any mouse events arriving during this window get echoed as raw escape sequence bytes.

The correct ordering already exists in @opentui/core's suspend() method, which calls disableMouse() before setRawMode(false).

Upstream issue: anomalyco/opentui#904
Upstream fix PR: anomalyco/opentui#905

Reproduction

1. Run opencode
2. Move the mouse while the TUI is active
3. Exit the TUI (quit or Ctrl+C)
4. Move the mouse in the shell immediately after exit
5. Garbled escape sequences appear

Workaround

A patchedDependencies patch for @opentui/core can fix this by adding disableMouse() + stdin drain before setRawMode(false) in cleanupBeforeDestroy(). A PR with this patch is forthcoming.

Environment

• macOS / Linux
• Affects @opentui/core@0.1.90 and @opentui/core@0.1.95

[github-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: Mouse wheel/movement causes garbled characters after closing OpenCode CLI (same symptom, cross-platform)
• [Windows] Hard-killed TUI leaves mouse reporting enabled; next launch does not reset terminal state #18901: Hard-killed TUI leaves mouse reporting enabled with raw escape sequences flooding the terminal (very similar root cause)
• In version 1.1.23, the issue of the mouse wheel triggering abnormal ASCII codes after exiting reappeared. #8908: Mouse wheel triggering abnormal ASCII codes after exiting (same symptom, reported as regression)
• Windows Command Prompt Mouse/Scroll Events Misbehave After Exiting "opencode" #12434: Mouse/scroll events misbehave after exiting OpenCode (same post-exit garbling issue)

Note that #18901 in particular is closely related — it describes the same core problem (mouse tracking not disabled on exit) from a slightly different angle (force-kill vs. normal exit). The root cause analysis in this issue may be relevant there as well.

[nikitalbnv]

I am seeing this same exit-time issue on Linux after closing OpenCode.

The raw text sometimes appears right after exit near my shell prompt. Examples:

997;1n
997;1n51;79;31M

Sometimes I see many of these, around 30 lines.

This happens across terminals:

Ghostty
Kitty
Alacritty

Environment:

OpenCode 1.14.25
tmux 3.6a
Arch Linux / Omarchy
Hyprland on Wayland

OpenCode path and version:

/home/nikita/.cache/.bun/bin/opencode
1.14.25

This seems separate from a Ghostty launcher crash I debugged. The escape text happens in any terminal, so it looks like OpenCode or OpenTUI cleanup is leaving terminal mouse/query responses to be echoed after exit.

[hertznsk]

+1, experiencing the same issue on Linux.

Environment:

• OS: Linux (Fedora)
• OpenCode version: 1.16.2
• Terminal: standard bash terminal

Symptoms:

1. At startup — before the TUI even renders, a stray sequence appears at the top:

   ^[[<35;83;40M
   

2. After exit — the sequence leaks into the shell prompt:

   user@host:~/projects$ 35;83;40M
   

The sequence 35;83;40M is an SGR mouse report (coordinates 83;40, button 35) that gets echoed after the terminal has already left raw mode. This matches the root cause described in the issue — setRawMode(false) re-enabling ECHO before mouse tracking is fully disabled.

The OPENCODE_DISABLE_MOUSE=true workaround prevents the issue, but obviously disables mouse support entirely.

Happy to provide any additional debugging info if needed.

[samuel-pro-ai]

Can confirm this is still happening on v1.17.3 (latest) with WSL Ubuntu + VS Code integrated terminal.

Reproduction:

1. Launch opencode in VS Code's integrated terminal (default profile: Ubuntu WSL)
2. Exit via built-in /exit command
3. Move the mouse over the terminal
4. Terminal spams: 35;75;9M35;72;8M35;70;8M... continuously

The terminal becomes unusable for typing until the VS Code terminal panel is closed and reopened. my ai said to add this when i asked about it: "reset, stty sane, and printf '\e[?1006l' all do not clear the buffered escape sequences."

Workaround: OPENCODE_DISABLE_MOUSE=1 works but kills mouse support inside the TUI - and using the mouse inside the tui is one of my favorite things.

This is a blocker for anyone using opencode inside VS Code + WSL.

[sheng-888]

Also reproduced on WSL2 + Windows Terminal (opencode 1.18.14): exit leaves
garbled SGR mouse sequences like 35;58;30M… on the shell line.

[tianq01]

Also reproduced on WSL2 + Windows Terminal (opencode 1.18.14): exit leaves garbled SGR mouse sequences like 35;58;30M… on the shell line.

I hit this issue too. on linux TUI terminal. this looks like a memory leak, the opencode process memory in top command grows much and TUI does not respond, and then the process crashes, the mouse escape sequences..

[WhiteGiverMa]

Confirming on WSL2 (Ubuntu 24.04) + Windows Terminal, OpenCode 1.18.18, bash.

Exiting via Ctrl+C / Ctrl+D leaves the same kind of SGR mouse fragments at the shell prompt:

celestia@Ayame:~/workspace$ 51;116;32M51;117;32M51;118;32M

Decoded: three consecutive mouse events at row 32, columns 116→117→118 — i.e. a horizontal mouse movement captured mid-exit.

Extra data point: deliberately wiggling the mouse during the exit produces proportionally more fragments. The garbage scales with real-time mouse activity in the teardown window, which is consistent with the root cause described above: stdin.setRawMode(false) re-enables terminal ECHO before mouse tracking is disabled in cleanupBeforeDestroy(), so live mouse events arriving in that window get echoed back as plain text. After the exit completes, moving the mouse produces no further fragments (tracking does get disabled eventually, just too late).

No such issue on the Windows Desktop (GUI) build, where the terminal is not involved.

Hoping anomalyco/opentui#905 can land soon.

[chriscarrollsmith]

I encountered this in MinGW/Git Bash (not WSL), so this is not exclusively a Linux issue.

[lyhnbomb]

Also confirming this on a different platform: Windows + MinTTY (Git Bash), opencode 1.18.32.

• OS: Windows 11 (MSYS_NT-10.0-26200)
• Terminal: MinTTY 3.8.3 (Git Bash)
• Shell: bash
• opencode: 1.18.32

Repro is the same: exit the TUI, then move the mouse at the shell prompt. The prompt line is flooded with the tail of SGR mouse sequences, e.g.:

35;125;49M35;123;49M35;122;49M35;122;48M35;121;48M...

The x value reaches ~244, which matches the terminal width in columns - confirming these are echoed mouse events. The line is redrawn on every mouse movement, so the window also flickers until reset is run.

Workaround for Git Bash users (re-send the disable sequences after opencode exits):

opencode() {
  command opencode "$@"
  printf '\e[?1000l\e[?1002l\e[?1003l\e[?1006l\e[?2004l'
}