Title
Raw SGR mouse-tracking escape codes printed as text in terminal when using TUI apps inside screen
Platform
Website - Other Browser
Server Installation Method
Docker
Version
v2.5.0
Troubleshooting
The Problem
Description:
When running a terminal TUI application (in my case, Anthropic's Claude Code CLI) inside a screen session over SSH via Termix's web terminal, moving the mouse causes raw SGR mouse-tracking escape sequences to be printed directly to the screen as visible text, instead of being interpreted/suppressed by the terminal.
Example of what gets printed:
35;191;1M35;186;2M35;46;21M35;38;20M35;29;19M35;20;18M...
Expected behavior:
Mouse movement should either be silently ignored/interpreted, or not produce visible garbage text in the terminal.
Actual behavior:
Raw SGR mouse-tracking coordinates (format ;;M) appear as literal text at the cursor position, corrupting the terminal display.
Environment:
Termix: web client
Client OS/browser: [vul hier je browser/OS in]
Server OS: Linux (LXC container)
Terminal multiplexer: GNU Screen 4.09.01
How to Reproduce
SSH into a Linux host via Termix's web terminal
Start a screen session: screen -S mysession
Inside the session, run a TUI app that enables mouse reporting (e.g. claude — Anthropic's Claude Code CLI)
Move the mouse over the terminal area
Additional Context
This appears to be related to how xterm.js-based terminals handle multiple simultaneous mouse-tracking modes (1000/1002/1003 button/motion tracking + 1006 SGR extended mode). When these modes propagate through a multiplexer layer like screen, some terminal emulators fail to fully suppress/interpret all of them.
I was able to reproduce this consistently regardless of how the screen session was started (manually attached, detached-then-reattached, or via a systemd service).
The issue occurs identically across two separate servers/environments, ruling out a server-specific configuration issue.
TERM was set to xterm-256color in both cases.
Running reset or printf '\e[?1000l\e[?1002l\e[?1003l\e[?1006l' clears the garbage output, suggesting Termix's terminal is not sending/processing the corresponding disable sequences correctly when the TUI app exits or during interaction.
Title
Raw SGR mouse-tracking escape codes printed as text in terminal when using TUI apps inside screen
Platform
Website - Other Browser
Server Installation Method
Docker
Version
v2.5.0
Troubleshooting
The Problem
Description:
When running a terminal TUI application (in my case, Anthropic's Claude Code CLI) inside a screen session over SSH via Termix's web terminal, moving the mouse causes raw SGR mouse-tracking escape sequences to be printed directly to the screen as visible text, instead of being interpreted/suppressed by the terminal.
Example of what gets printed:
35;191;1M35;186;2M35;46;21M35;38;20M35;29;19M35;20;18M...
Expected behavior:
Mouse movement should either be silently ignored/interpreted, or not produce visible garbage text in the terminal.
Actual behavior:
Raw SGR mouse-tracking coordinates (format ;;M) appear as literal text at the cursor position, corrupting the terminal display.
Environment:
Termix: web client
Client OS/browser: [vul hier je browser/OS in]
Server OS: Linux (LXC container)
Terminal multiplexer: GNU Screen 4.09.01
How to Reproduce
SSH into a Linux host via Termix's web terminal
Start a screen session: screen -S mysession
Inside the session, run a TUI app that enables mouse reporting (e.g. claude — Anthropic's Claude Code CLI)
Move the mouse over the terminal area
Additional Context
This appears to be related to how xterm.js-based terminals handle multiple simultaneous mouse-tracking modes (1000/1002/1003 button/motion tracking + 1006 SGR extended mode). When these modes propagate through a multiplexer layer like screen, some terminal emulators fail to fully suppress/interpret all of them.
I was able to reproduce this consistently regardless of how the screen session was started (manually attached, detached-then-reattached, or via a systemd service).
The issue occurs identically across two separate servers/environments, ruling out a server-specific configuration issue.
TERM was set to xterm-256color in both cases.
Running reset or printf '\e[?1000l\e[?1002l\e[?1003l\e[?1006l' clears the garbage output, suggesting Termix's terminal is not sending/processing the corresponding disable sequences correctly when the TUI app exits or during interaction.