Pimp My IDE / garage dispatch
Back to garage
September 28, 2026 | terminals / input / TUIs

Decide who owns the click.

A full-screen terminal app shares one keyboard and mouse with the terminal emulator. Selection, right-click, paste, links, and fast key bursts need an explicit owner.

If the app captures an input, it must expose the action, the bypass, and the resulting state. Otherwise the terminal feels random.

Terminal apps now compete with the terminal.

A shell leaves most mouse behavior to its terminal emulator. A full-screen terminal user interface can ask for mouse events and turn the same click into navigation, selection, a context menu, or nothing. Hntui documents this boundary in plain terms. Its mouse mode intercepts normal drag selection, so users hold Option on macOS or Shift on Linux to give the gesture back to the terminal.[1]

Windows Terminal documents the same ownership switch. When an application uses virtual-terminal mouse input, Shift makes a selection instead of sending the mouse event to the application. The terminal also lets right-click copy a selection and paste when no selection remains.[2]

One gesture can cross two state machines before it reaches your prompt.

Copy settings change the meaning of right-click.

Codex 0.158.0 added configurable copy-on-select and right-click paste to its full-screen interface. Copied transcript selections can preserve Markdown formatting.[3] Those options are useful because they name behavior that users otherwise have to discover by accident.

Copy-on-select also changes the state beneath the pointer. Windows Terminal notes that with this option enabled, right-click can copy the active selection and paste it into the terminal. A second click may therefore become input to a running command. The safe default depends on the terminal, the application, and whether mouse mode is active.

Keyboard ownership has a timing contract.

Claude Code 2.1.283 fixed fast key bursts that could be handled against stale interface state. The release calls out type-ahead, key repeat, SSH, and tmux.[4] This is not a cosmetic defect. If the highlighted row changes after the key was interpreted, the visible target and the activated target can disagree.

The same release fixed keybinding documentation, stale footer hints after rebinding, Vim-mode edge cases, and screen-reader output for permission dialogs. These fixes point to one rule. A shortcut is complete only when its timing, visible hint, focus owner, and accessible result agree.

Run an input lap before daily use.

  1. Open the app in the terminal you use at work. Repeat the test inside tmux or SSH if those are part of the route.
  2. Select wrapped text with the mouse. Copy it. Confirm the bytes, line breaks, and formatting you expected.
  3. Right-click with and without a selection. Confirm that paste cannot surprise you at a live prompt.
  4. Hold a navigation key, type ahead during a view change, and use every displayed escape key. The visible state must match the action.
  5. Repeat the main route without a mouse. Check focus, link access, permission prompts, and screen-reader text if your team depends on them.

Write the result for the exact terminal, app version, multiplexer, and remote route. "Works in a terminal" is not a useful input contract.

Interactive makeover / input ownership shifter

Input arbitration bench

Traditional purpose replaced: a static shortcut list. Better version: choose the active terminal mode, select the behaviors you tested, and copy a route-specific test card. This bench plans a test. It does not inspect your terminal.

Shift the active owner

The native radio control is the source of truth. The carriage mirrors the selected input mode.

Terminal mode under test
Observed behavior checks
No behavior check is selectedThe mode is set to Mouse TUI. Record the terminal before testing selection.
Copyable input test card

Record the whole route

Replace every required field with results from your own setup.

What this component proves. It keeps terminal mode, selection, right-click, key timing, and access in one review card. It does not capture native events, read terminal settings, or prove safe paste behavior.

Sources and limits

Open the source log
  1. Hntui repository and README, read September 28, 2026. The README documents keyboard and mouse controls, the mouse-capture selection bypass, persistent saved items, supported binaries, and the author's platform-test limits.
  2. Windows Terminal selection documentation, read September 28, 2026. Microsoft documents mouse mode, Shift selection, right-click copy and paste, keyboard selection, copy formatting, and copy-on-select behavior.
  3. Codex 0.158.0 release notes, published September 28, 2026. OpenAI lists configurable copy-on-select, right-click paste, and Markdown-preserving transcript copy in the full-screen terminal interface.
  4. Claude Code 2.1.283 release notes, published September 25, 2026. Anthropic lists fixes for stale-state key bursts, rebinding hints, Vim-mode input, Warp links, and permission-dialog screen-reader output.
  5. Hacker News discussion for Hntui, item 49876760, read September 28, 2026. This was the discovery trail. It does not verify the application behavior described by the project.

Evidence boundary. The release notes describe vendor fixes. We did not reproduce those defects across terminals, multiplexers, remote shells, or assistive technology. The test card is a review template, not compatibility evidence.