hermes - 💡(How to fix) Fix [Bug]: Mouse tracking escape sequences leak into input buffer (raw SGR mouse codes appear in prompt input)

Bug Description

Bug Report

Summary

When using HermesAgent in a terminal with mouse tracking enabled, raw SGR mouse tracking escape sequences leak into the prompt input field. The input field displays garbage like ;29;29M4;29;29M64;51;26M26M3;26M26M21M8... instead of user-typed text.

Environment

• OS: Linux (specific distro: [your distro, e.g. Ubuntu 22.04])
• Terminal emulator: [e.g. kitty / tmux / iTerm2 / Windows Terminal]
• HermesAgent version: [version or commit hash]
• Shell: [e.g. bash / zsh]

Steps to Reproduce

1. Launch HermesAgent in a terminal session
2. Wait for the prompt input to be ready
3. Move the mouse or click within the terminal window
4. Observe the input field — raw escape sequence characters appear automatically

Actual Behavior

The input buffer receives raw bytes that appear to be SGR mouse tracking escape sequences:

;29;29M4;29;29M64;51;26M26M3;26M26M21M8;23M;138;26M38;24M138;21M7M;19M5;109;19M;108;20M5;98;23M;25M28M8M5;113;29M;126;33M20;34M35;23;29M21;28MM;27M6MM[IM32M;94;26M35;71;33M1M35;96;31M5;86;33M5M[O81;6MM6;33M32M0;35M35MM9;30M35;15;30M8;29M3M9;5M99;1M

These appear to be SGR mouse protocol events (\e[<row;col;buttonM) with the leading \e[< stripped, indicating the escape prefix is consumed but the payload is passed to the input handler.

Expected Behavior

Mouse tracking events should be silently consumed by the TUI framework and never reach the input buffer. The input field should only contain characters typed by the user.

Root Cause (suspected)

HermesAgent enables mouse tracking mode (\e[?1000h / \e[?1006h SGR mode) but the input component does not properly filter out mouse event sequences from the read loop. When raw mouse reports arrive on stdin, the input reader treats them as user keystrokes.

Possible Fix

• Ensure mouse event sequences are fully consumed in the event/key-read loop before being passed to the input widget
• If using a TUI library (e.g. bubbletea, tview, tcell), verify that mouse event handling is registered correctly so events are dispatched to mouse handlers rather than the key/rune reader
• On exit or when the input loses focus, send \e[?1000l\e[?1006l to disable mouse tracking

Screenshots

[attach the screenshot here]

Steps to Reproduce

1. Launch HermesAgent in a terminal session
2. Wait for the prompt input to be ready
3. Move the mouse or click within the terminal window
4. Observe the input field — raw escape sequence characters appear automatically

Expected Behavior

Mouse tracking events should be silently consumed by the TUI framework and never reach the input buffer. The input field should only contain characters typed by the user.

Actual Behavior

The input buffer receives raw bytes that appear to be SGR mouse tracking escape sequences:

;29;29M4;29;29M64;51;26M26M3;26M26M21M8;23M;138;26M38;24M138;21M7M;19M5;109;19M;108;20M5;98;23M;25M28M8M5;113;29M;126;33M20;34M35;23;29M21;28MM;27M6MM[IM32M;94;26M35;71;33M1M35;96;31M5;86;33M5M[O81;6MM6;33M32M0;35M35MM9;30M35;15;30M8;29M3M9;5M99;1M

These appear to be SGR mouse protocol events (\e[<row;col;buttonM) with the leading \e[< stripped, indicating the escape prefix is consumed but the payload is passed to the input handler.

Affected Component

CLI (interactive chat)

Messaging Platform (if gateway-related)

No response

Debug Report

Report       https://paste.rs/sKfgt
agent.log    https://paste.rs/MOFya
gateway.log  https://paste.rs/ujAd4

Operating System

20.04

Python Version

No response

Hermes Version

No response

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR