Skip to content

[Bug] Terminal flooded with raw mouse escape sequences (SGR) when running commands #26198

New issue
New issue
Closed as not planned
Closed as not planned
[Bug] Terminal flooded with raw mouse escape sequences (SGR) when running commands#26198
Assignees
kommander

Description

@toi500
toi500
opened on May 7, 2026

Description

I ran into a frustrating bug.

The CLI enables mouse tracking in the terminal, but if a process runs or gets interrupted, it fails to send the escape sequence to disable mouse tracking before handing control back to the prompt. As a result, the terminal gets stuck in raw mouse reporting mode.

Any tiny mouse movement over the terminal window instantly floods the command line with ANSI SGR coordinates ([555;100;66M), making it impossible to type.

Environment

  • OS: Windows 11
  • Terminal: Windows Terminal (PowerShell)
  • OpenCode Version: 1.14.40 (Saw this in other previous version too)

Steps to Reproduce

The model decides on its own to execute a system command (in my case, the DeepSeek V4 pro it needed to run Stop-Process to kill a stale Node server).

Expected Behavior

Because OpenCode uses mouse tracking for interactivity, it is expected that the terminal remains in mouse-tracking mode while the CLI is active. However, when the CLI hands control back to the standard shell (such as when executing a system command like Stop-Process), it must either:

  1. Disable tracking (via \x1b[?1000l or \x1b[?1006l) before the prompt is returned to the user, OR
  2. Suspend tracking during the execution of child processes and resume it immediately after, ensuring that shell input is never interpreted as mouse coordinates.

Currently, the CLI appears to lose track of its state during the process execution, leaving the terminal in a dirty state where mouse events are leaked into the standard input buffer.

Actual Behavior

The terminal captures the mouse movements as literal text inputs. My prompt gets spammed with a massive block of gibberish like this:
-[555;100;66M[555;100;67M[555;100;68M[555;100;69M[555;...

Screenshots

Image

Activity

  1. github-actions
    assigned
    kommander
    on May 7, 2026

  2. github-actions commented on May 7, 2026

    @github-actions
    github-actionsBot
    on May 7, 2026 – with GitHub Actions
    Contributor

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

    If your issue is not already covered by these, please add any additional context that distinguishes it.

  3. toi500 commented on May 7, 2026

    @toi500
    toi500
    on May 7, 2026
    Author

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

    If your issue is not already covered by these, please add any additional context that distinguishes it.

    This issue started happening again in v1.14.40 on Windows 11. I have reviewed the existing issues listed above (especially #20458), and while they share the same symptoms, it’s clear the fix is either incomplete or regressing.

    It is frustrating to see this persist, especially since the technical cause, incorrect ordering of stdin.setRawMode(false) and disableMouse(), has been identified before. If the terminal is taken out of raw mode before the \x1b[?1000l (or 1006l) sequence is sent, those characters are echoed back to the prompt as literal text.

    I am reporting this because the dirty state is still leaking into the shell in the latest release. This deserves a permanent fix in the core TUI lifecycle rather than relying on users to manually reset their terminals.

  4. toi500 commented on May 7, 2026

    @toi500
    toi500
    on May 7, 2026
    Author

    Note: I have also confirmed that this issue persists when running Ubuntu via WSL2. This suggests the bug isn't just isolated to the Windows console driver, but is a fundamental issue in the CLIs TUI cleanup logic across different shell environments, I guess.

  5. toi500 commented on May 8, 2026

    @toi500
    toi500
    on May 8, 2026
    Author

    @kommander, still happening in v1.14.41 too.

    Image

  6. thdxr commented on May 8, 2026

    @thdxr
    thdxr
    on May 8, 2026
    Member

    we're having a hard time reproducing this. what is killing the process?

  7. toi500 commented on May 9, 2026

    @toi500
    toi500
    on May 9, 2026
    Author

    @thdxr as I mentioned in the steps to reproduce, the model itself is executing the kill command. In my case, DeepSeek V4 Pro decided to run Stop-Process in PowerShell to kill a stale Node server.

    However, I want to add that this has now happened twice in v1.14.41. At first, I thought it was just a corrupted session from my previous setup, so I did a completely clean/hard uninstall of OpenCode (wiping the app, all configs, everything).

    After the clean install, it happened again on v1.14.41, this time while using a Kimi model. This second time, it wasn't even a kill process (I can't remember exactly what command it ran because the terminal instantly went completely crazy).

    IMHO, this suggests it's not just tied to Stop-Process, but rather any command execution/hand-off by the model can potentially interrupt the TUI lifecycle and leave the terminal flooded.

  8. SpaceZhenya commented on May 9, 2026

    @SpaceZhenya
    SpaceZhenya
    on May 9, 2026

    I have the same proplem too!

  9. toi500 commented on May 11, 2026

    @toi500
    toi500
    on May 11, 2026
    Author

    @thdxr, version 1.14.48

    I just asked the LLM to run $ Get-Process -Name node -ErrorAction SilentlyContinue | Stop-Process -Force

    Image

  10. toi500 commented on May 15, 2026

    @toi500
    toi500
    on May 15, 2026
    Author

    Happened again. It keeps breaking long context sessions, corrupting any well crafted session you try to build.
    Just frustrating.

    Image

  11. l246804 commented on May 15, 2026

    @l246804
    l246804
    on May 15, 2026

    The same issue occurs in Linux environments. Reproduction only occurs when there are a large number of contexts in the session memory; exiting normally occurs with few or no contexts.

    Image

  12. kommander commented on May 15, 2026

    @kommander
    kommander
    on May 15, 2026
    Contributor

    @toi500 you are asking the model to kill all node processes and it seems to identify opencode as node process and kills it. Killed that way the process has no way to do cleanup.

  13. thdxr commented on May 15, 2026

    @thdxr
    thdxr
    on May 15, 2026
    Member

    i am getting rid of the node wrapper when installed via npm - has been on our list for a while but no one could get to it

  14. toi500 commented on May 15, 2026

    @toi500
    toi500
    on May 15, 2026
    Author

    @toi500 you are asking the model to kill all node processes and it seems to identify opencode as node process and kills it. Killed that way the process has no way to do cleanup.

    No. If you read this issue in full, you will see that neither I nor other users are asking the model to kill anything. What you see here #26198 (comment) it was just a easy way to show how to reproduce the bug.

    I handle any manual processes on my own, but as you are well aware, I am in control of what the model does.

  15. kommander commented on May 15, 2026

    @kommander
    kommander
    on May 15, 2026
    Contributor

    you will see that neither I nor other users are asking the model to kill anything

    What is this if not asking the model to kill processes? It identifies the opencode process as node process and kills it, at that point there is nothing any process/app can do to cleanup properly.

    Image

  16. toi500 commented on May 15, 2026

    @toi500
    toi500
    on May 15, 2026
    Author

    What?
    I just told you that was my way to tell @thdxr how to reproduce the bug.

    Image

    Original Issue:

    Image

    Other users:

    Image Image Image

    Please do not ping me again unless you want to discuss the actual technicality of the issue. I am not here for excuses or to waste my time.

  17. SpaceZhenya commented on May 27, 2026

    @SpaceZhenya
    SpaceZhenya
    on May 27, 2026 via email

  18. github-actions commented on Jul 27, 2026

    @github-actions
    github-actionsBot
    on Jul 27, 2026 – with GitHub Actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

  19. github-actions
    closed this as not plannedon Jul 27, 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