Skip to content

bug: mouse escape sequences garbled after TUI exit #20458

Closed as duplicate
Closed as duplicate
bug: mouse escape sequences garbled after TUI exit#20458
Assignees
kommander

Description

@agutmanstein-scale
agutmanstein-scale
opened on Apr 1, 2026

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

Activity

  1. github-actions
    assigned
    kommander
    on Apr 1, 2026
  2. github-actions
    added
    opentuiThis relates to changes in v1.0, now that opencode uses opentui
    on Apr 1, 2026

  3. github-actions commented on Apr 1, 2026

    @github-actions
    github-actionsBot
    on Apr 1, 2026 – with GitHub Actions
    Contributor

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

    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.

  4. agutmanstein-scale
    added a commit that references this issue on Apr 1, 2026

    fix(tui): patch @opentui/core to prevent mouse garbling on exit and f…

    6057e11
  5. 18vijayb
    added a commit that references this issue on Apr 2, 2026

    fix(tui): patch @opentui/core to prevent mouse garbling on exit and f…

    929adfa
  6. agutmanstein-scale
    added a commit that references this issue on Apr 2, 2026

    fix(tui): patch @opentui/core to prevent mouse garbling on exit and f…

    dde7edd

  7. nikitalbnv commented on Apr 25, 2026

    @nikitalbnv
    nikitalbnv
    on Apr 25, 2026

    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.

  8. thdxr
    removed
    opentuiThis relates to changes in v1.0, now that opencode uses opentui
    on May 3, 2026

  9. hertznsk commented on Jun 7, 2026

    @hertznsk
    hertznsk
    on Jun 7, 2026

    +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.

  10. samuel-pro-ai commented on Jun 12, 2026

    @samuel-pro-ai
    samuel-pro-ai
    on Jun 12, 2026

    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.

  11. sheng-888 commented on Aug 6, 2026

    @sheng-888
    sheng-888
    on Aug 6, 2026

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

  12. tianq01 commented on Aug 13, 2026

    @tianq01
    tianq01
    on Aug 13, 2026

    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..

  13. WhiteGiverMa commented on Aug 16, 2026

    @WhiteGiverMa
    WhiteGiverMa
    on Aug 16, 2026

    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.

  14. chriscarrollsmith commented on Aug 20, 2026

    @chriscarrollsmith
    chriscarrollsmith
    on Aug 20, 2026

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

  15. lyhnbomb commented on Sep 22, 2026

    @lyhnbomb
    lyhnbomb
    on Sep 22, 2026

    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'
}

  16. djbclark commented on Sep 27, 2026

    @djbclark
    djbclark
    on Sep 27, 2026

    Related but distinct trigger documented in #51600: on macOS/Bash, OpenCode v1 can become job-control stopped automatically after startup (confirmed SIGTTOU 22 in default mode and SIGTTIN 21 in attach mode). Because the stop bypasses teardown, mouse reporting remains enabled and produces the same 35;...M stream described here. --pure does not prevent it; temporarily running the TUI with Bash monitor mode disabled does. OpenCode v2.0.18 did not reproduce in the same PTY test.

  17. neriousy commented on Oct 1, 2026

    @neriousy
    neriousy
    on Oct 1, 2026
    Member

    Closing as a duplicate of #11748, which tracks mouse escape sequences showing up as garbled text in the terminal after OpenCode exits. Please add your platform and terminal details there.

  18. neriousy
    closed this as a duplicateof After closing the OpenCode CLI, scrolling the mouse wheel and moving the mouse in the powershell will cause garbled characters. #11748 on Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions