What does this PR do?

Adds right-click-to-paste in the React/Ink TUI. Previously, SGR mouse tracking inside the alt screen swallowed right-clicks (handleMouseEvent early-returned on non-left presses), which meant the terminal's native right-click paste was intercepted by the app but never wired to anything — users had to reach for Alt+V or /paste.

The fix dispatches middle/right-button presses through the DOM event system just like left-clicks, and has TextInput listen for button 2 and route it into the existing clipboard-paste hotkey path (same as Alt+V / /paste). This reuses the gateway's clipboard.paste RPC for free, so right-click handles both text and image clipboard content identically to the existing hotkey.

Approach rationale:

• Modifying @hermes/ink's App.tsx to forward non-left presses (instead of swallowing them) is the minimal change and doesn't touch selection, multi-click, or hyperlink logic. Non-left presses intentionally skip mouseCaptureTarget so they don't start a drag capture.
• Reusing emitPaste({ hotkey: true }) in TextInput keeps all clipboard logic (image attach, text surface, OSC 52 fallback, Linux clipboard tool probing) in one place — the composer's handleTextPaste already branches on hotkey: true to call onClipboardPaste.

Related Issue

Fixes #

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• ui-tui/packages/hermes-ink/src/ink/components/App.tsx — in handleMouseEvent, forward middle/right-button presses (baseButton !== 0) to onMouseDownAt instead of dropping them. Deliberately does not set mouseCaptureTarget so non-left releases stay a no-op in the existing release path.
• ui-tui/src/components/textInput.tsx — add onMouseDown on the outer Box that filters for SGR button 2 (right-click) and calls emitPaste({ hotkey: true, text: '', ... }), which funnels into the existing Alt+V path via useComposerState.handleTextPaste.
• ui-tui/packages/hermes-ink/dist/ink-bundle.js — rebuilt (npm run build --prefix packages/hermes-ink).

How to Test

1. cd hermes-agent/ui-tui && npm run dev
2. Copy some text to your system clipboard (or a screenshot/image on macOS).
3. In the TUI composer, right-click anywhere in the input area — clipboard text gets inserted (small paste) or collapsed to a token (large paste); clipboard images get attached with 📎 Image #N attached from clipboard.
4. Confirm behavior matches pressing Alt+V.
5. Verify left-click still repositions the cursor, double-click still word-selects, drag-select still works, and middle-click is a no-op.
6. Test on a terminal that forwards right-click (iTerm2, WezTerm, Alacritty, Windows Terminal, Kitty, Ghostty). On macOS Terminal.app or a terminal that doesn't forward right-click, users can fall back to Shift+right-click (native terminal paste) or Alt+V — unchanged behavior.

Automated:

cd hermes-agent/ui-tui
npm run type-check   # passes
npm run lint         # passes
npm test             # 92/92 passing

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass — N/A (TUI-only change; ran npm test in ui-tui/, 92/92 pass)
• I've added tests for my changes (required for bug fixes, strongly encouraged for features) — manual verification only; the mouse-dispatch path has no existing unit-test harness in ui-tui/src/__tests__/
• I've tested on my platform: Ubuntu 24.04 (WSL2) — Windows Terminal + tmux

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A (behavior parallels existing Alt+V hotkey; content/hotkeys.ts already lists the clipboard paste affordance)
• I've updated cli-config.yaml.example if I added/changed config keys — N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — relies on the existing clipboard.paste gateway RPC which already handles pbpaste / wl-paste / xclip / xsel / PowerShell; no new platform code
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

Screenshots / Logs