I’m having an issue with text selection, copying, and scrolling inside the Hermes TUI.

[velvet flower]

Hi,

I’m having an issue with text selection, copying, and scrolling inside the Hermes TUI.

Summary of the issue:

When Hermes TUI is open, native terminal text selection does not work properly unless I disable mouse tracking with /mouse. If I disable mouse tracking, I can select text and copy it with Cmd+C, but then I can only select the text currently visible on the screen. I cannot drag the selection upward past the top of the window to autoscroll and select previous lines.

When /mouse is enabled, I can scroll normally inside the TUI using the mouse wheel, but native terminal text selection/copying does not work properly. I also cannot select a long response and drag upward to include earlier lines in the selection.

Behavior:

• With /mouse disabled:
  • Native terminal text selection and Cmd+C copying work.
  • However, when selecting text, I cannot drag upward beyond the visible TUI viewport.
  • Autoscroll either does not happen or is very limited.
  • As a result, I can only copy the portion currently visible on screen.
• With /mouse enabled:
  • Mouse wheel scrolling inside the TUI works.
  • Native terminal text selection does not work properly.
  • I cannot select text and drag upward to copy a longer section.
  • Copying is effectively not usable for long TUI responses.

Expected behavior:

When selecting text with the mouse and dragging the cursor toward the top edge of the window, the TUI or terminal should scroll upward and allow earlier lines outside the visible viewport to be included in the selection. This would make it possible to copy long Hermes responses or log output in one piece.

Environment:

• macOS
• Hermes TUI
• Cmd+C works for copying when text can be selected
• The issue mainly happens when trying to copy long TUI responses by selecting text and dragging upward

Could this be related to Hermes TUI mouse handling, alternate screen buffer behavior, or terminal scrollback integration? Is there a recommended setting, shortcut, or workaround for copying long responses directly from the TUI?

Thanks.

[lunar nacelle]

@tidal hinge what do you think of this issue?

[tidal hinge]

💻 terminal: "gh issue list --repo NousResearch/her..."

classic TUI mouse tracking vs. terminal text selection tension. let me check if there's an existing issue and look at the relevant code.

🔎 search_files: "mouse|MouseTracking|altscreen|alterna..."
🐍 execute_code: "from hermes_tools import terminal res..."
🔎 search_files: "mouse"

gh auth isn't flowing through execute_code. Let me check the relevant TUI source directly and search issues via the web.

📄 web_extract: "https://github.com/NousResearch/herme..."
📖 read_file: "/home/daimon/github/hermes-agent/ui-t..."
🔎 search_files: "useSelection|useHasSelection|autoscro..."

good — there's already a known issue (#23159) that mentions mouse selection broken in TUI over SSH. but the user's problem is more nuanced — specifically the cross-viewport drag selection autoscroll gap on macOS. let me look at the selection implementation.

📖 read_file: "/home/daimon/github/hermes-agent/ui-t..."
🔎 search_files: "captureScrolledRows|shiftAnchor|shift..."

now let me look at what the selection API exposes around autoscroll and whether it handles drag-to-scroll:

📖 read_file: "/home/daimon/github/hermes-agent/ui-t..."
🔎 search_files: "drag|autoscroll|edge.scroll|scroll...."

now I have a very clear picture. let me check the mouse event handler to see how drag-to-edge autoscroll is handled:

📖 read_file: "/home/daimon/github/hermes-agent/ui-t..."

[tidal hinge]

I now have a very clear picture of the full situation. Here's what I found:

---

tl;dr: this is a fundamental terminal architecture constraint, not a bug. But there are good workarounds.

What's actually happening:

The TUI uses the @hermes/ink framework in alternate screen mode with its own mouse tracking layer. The two modes you're experiencing are an inherent trade-off:

• /mouse on — Ink captures all mouse events (SGR mouse protocol). The terminal emulator's native text selection is suppressed because the app owns the mouse. TUI drag-to-scroll within the viewport works. Ink's selection system has a captureScrolledRows + shiftAnchor mechanism to handle selection during programmatic scroll (triggered by wheel), but there's no edge-detection autoscroll loop — dragging the cursor to row 0 of the viewport does not trigger a scroll. Looking at scroll.ts, scrollWithSelectionBy only runs on explicit wheel/keyboard scroll events. There's no mousemove-to-top-edge handler that fires scrollTranscript(-1) on a timer.

• /mouse off — Native terminal text selection works, including Cmd+C. But you're limited to what's visible in the alternate screen buffer, which doesn't have scrollback. The terminal's scrollback belongs to the primary screen; the TUI renders into altscreen, so there's simply no history above the fold to drag into.

The code at ui-tui/src/app/useMainApp.ts:155-187 even has a comment explicitly acknowledging the macOS Cmd+C interception problem and implementing a copy-on-select workaround (iTerm-style: selection is auto-copied to clipboard on drag-end).
(1/2)

What's missing: a drag-edge autoscroll loop — when the mouse is held down and dragging near row 0 of the viewport, fire a repeating scrollTranscript(-1) until drag ends or mouse moves away from the edge. This is the standard pattern for this in GUI frameworks, but it requires hooking mousemove events near the viewport edge, which Ink doesn't expose natively.

Best workarounds right now:

1. Copy long responses via the TUI's built-in keyboard copy — with /mouse on, drag to select, then when you let go the selection is auto-copied to clipboard (macOS copy-on-select is implemented). You don't need Cmd+C; just complete the drag and the text is already in your clipboard.

2. Use Shift+↑/↓ or PageUp to scroll while /mouse is off, then select what's visible and Cmd+C it in chunks.

3. Pipe output — if you need the full text of a long response, use hermes --no-tui or redirect to a file: hermes "your query" > out.txt.

4. iTerm2 specifically supports holding Option/Alt while clicking to do "rectangular selection" that bypasses mouse tracking even when enabled — may help in some cases.

This is a known gap — issue #23159 touches it. The proper fix would be implementing drag-edge autoscroll in the Ink mouse event layer. Worth filing a dedicated issue for the autoscroll gap specifically if you want to track it. Tag @teknium to get it on the radar since I can't file issues directly. (2/2)

[lunar nacelle]

does this help you out @velvet flower ?