Skip to content

Console mode corruption in long-running TUI sessions causes mouse selection and copy/paste to stop working #19674

@pkellyuk

Description

@pkellyuk

Description

During long-running TUI (Terminal User Interface) sessions in Windows Terminal, console mode flags become corrupted over time, causing mouse selection, scrollbar interaction, and copy/paste functionality to stop working. This affects multiple TUI applications including opencode and mistral-vibe.

Environment

  • Windows Terminal Version: (affects latest versions including 1.21+)
  • Windows Version: Windows 10/11
  • Affected Applications: TUI applications built with various frameworks (@OpenTui, Python Textual, etc.)
  • Onset: Typically occurs after 30+ minutes of continuous use

Steps to Reproduce

  1. Open Windows Terminal
  2. Launch a long-running TUI application (e.g., opencode, mistral-vibe, or similar)
  3. Use the application normally for 30+ minutes with mouse interactions
  4. Attempt to:
    • Use mouse to select text
    • Click on the scrollbar
    • Copy selected text with Ctrl+C or right-click

Expected Behavior

Mouse selection, scrollbar, and copy/paste should continue working throughout the entire session regardless of duration.

Actual Behavior

After approximately 30+ minutes of use:

  • Mouse selection stops working or becomes unresponsive
  • Scrollbar becomes unresponsive to clicks
  • Copy/paste functionality fails
  • Mouse input feels "broken" or inconsistent

Root Cause Analysis

Through investigation, we've identified that Windows console mode flags are being corrupted during long-running sessions. Specifically:

Console Mode Flags Affected:

  • ENABLE_MOUSE_INPUT (0x0010)
  • ENABLE_QUICK_EDIT_MODE (0x0040)
  • ENABLE_EXTENDED_FLAGS (0x0080)
  • ENABLE_VIRTUAL_TERMINAL_INPUT (0x0200)
  • ENABLE_VIRTUAL_TERMINAL_PROCESSING (0x0004)

The corruption appears to happen at the ConPTY or console host level, not within the TUI application itself.

Workaround

We've successfully worked around this issue by periodically calling SetConsoleMode via Windows API to refresh the console mode flags:

  1. Save original console modes on startup
  2. Periodically refresh console modes (every 30 seconds) using kernel32.dll functions:
    • GetStdHandle(STD_INPUT_HANDLE) / GetStdHandle(STD_OUTPUT_HANDLE)
    • GetConsoleMode() to read current modes
    • SetConsoleMode() to restore correct flags
  3. Ensure ENABLE_VIRTUAL_TERMINAL_PROCESSING and ENABLE_MOUSE_INPUT remain enabled
  4. Disable ENABLE_QUICK_EDIT_MODE when it interferes with TUI mouse handling

Implementation examples:

The fact that this workaround is necessary and effective confirms that console modes are being corrupted by the system rather than by applications.

Related Issues

This appears distinct from:

Unlike those issues, this is about console mode flags being changed/corrupted by Windows/ConPTY during normal operation, not about applications being unable to set modes.

Impact

This affects any long-running TUI application on Windows Terminal where mouse interaction is critical to the user experience. Users must restart their TUI applications or implement platform-specific workarounds to maintain functionality.

Questions for Maintainers

  1. Is there any known mechanism in ConPTY or the console host that modifies console mode flags during runtime?
  2. Could Windows accessibility features or other system processes be interfering with console modes?
  3. Should applications expect console modes to remain stable once set, or is periodic refreshing the expected pattern?
  4. Is this something that should be fixed in Windows Terminal/ConPTY, or is the application-level workaround the recommended approach?

Additional Context

This issue affects TUI frameworks across multiple languages and platforms (Python, TypeScript/Node.js, etc.), suggesting it's a Windows Terminal/ConPTY-level issue rather than a framework-specific problem.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Needs-Tag-FixDoesn't match tag requirementsNeeds-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions