Bug Description
When launching Hermes Agent with hermes --tui from a Linux terminal, copy and paste from the TUI to the system clipboard does not work.
This is a GNOME Terminal 3.60.0 + VTE 0.84.0 issue — GNOME Terminal does not implement OSC52 clipboard sequences, which is the primary clipboard mechanism the TUI relies on.
Environment
- Terminal: GNOME Terminal 3.60.0 (VTE 0.84.0 +BIDI +GNUTLS +ICU +SYSTEMD)
- Platform: Linux (Fedora 44, x86_64)
- Display Server: Wayland (
WAYLAND_DISPLAY=wayland-0)
- TERM: xterm-256color
- Invocation:
hermes --tui from CLI
Expected Behavior
The TUI uses OSC52 (Operating System Command 52) to read from and write to the system clipboard:
- Copy from TUI: When text is selected and copied, the TUI writes to the system clipboard via OSC52.
- Paste to TUI: When the user pastes, the TUI reads from the system clipboard via OSC52.
On terminals that support OSC52 (xterm, iTerm2, Alacritty, Kitty, tmux with passthrough enabled), this works correctly.
Actual Behavior
- Copy: OSC52 write is sent, but GNOME Terminal ignores it — text is never copied to the system clipboard.
- Paste: OSC52 read query is sent, but GNOME Terminal does not respond with clipboard contents, so paste returns null/empty.
The TUI has native fallback tools available:
- wl-paste is installed and works correctly (
wl-paste --type text returns clipboard content).
clipboard.ts tries xclip first on Linux X11, then wl-paste for Wayland — but the OSC52 path is attempted first and fails silently on GNOME Terminal.
Relevant Code
ui-tui/src/lib/osc52.ts — OSC52 clipboard read/write
ui-tui/src/lib/clipboard.ts — fallback chain (pbpaste → powershell → wl-paste → xclip)
ui-tui/src/components/textInput.tsx — paste handling
ui-tui/src/lib/platform.ts — platform/terminal detection
tui_gateway/server.py — clipboard.paste RPC method
Proposed Fix
Detect GNOME Terminal via GNOME_TERMINAL_SERVICE or VTE_VERSION environment variables, and skip OSC52 in favor of native clipboard tools:
| Terminal |
OSC52 Copy |
OSC52 Paste |
Native Tool |
| xterm |
✅ |
✅ |
— |
| iTerm2 |
✅ |
✅ |
— |
| Alacritty |
✅ |
✅ |
— |
| Kitty |
✅ |
✅ |
— |
| GNOME Terminal |
❌ |
❌ |
wl-paste / xclip |
| Windows Terminal |
✅ |
✅ |
— |
Logs
01-hermes-debug-output.txt
02-system-env-diagnostics.txt
04-issue-body.txt
README.txt
Tags
- comp/tui
- type/bug
- clipboard
- gnome-terminal
- osc52
- linux
Bug Description
When launching Hermes Agent with
hermes --tuifrom a Linux terminal, copy and paste from the TUI to the system clipboard does not work.This is a GNOME Terminal 3.60.0 + VTE 0.84.0 issue — GNOME Terminal does not implement OSC52 clipboard sequences, which is the primary clipboard mechanism the TUI relies on.
Environment
WAYLAND_DISPLAY=wayland-0)hermes --tuifrom CLIExpected Behavior
The TUI uses OSC52 (Operating System Command 52) to read from and write to the system clipboard:
On terminals that support OSC52 (xterm, iTerm2, Alacritty, Kitty, tmux with passthrough enabled), this works correctly.
Actual Behavior
The TUI has native fallback tools available:
wl-paste --type textreturns clipboard content).clipboard.tstriesxclipfirst on Linux X11, thenwl-pastefor Wayland — but the OSC52 path is attempted first and fails silently on GNOME Terminal.Relevant Code
ui-tui/src/lib/osc52.ts— OSC52 clipboard read/writeui-tui/src/lib/clipboard.ts— fallback chain (pbpaste → powershell → wl-paste → xclip)ui-tui/src/components/textInput.tsx— paste handlingui-tui/src/lib/platform.ts— platform/terminal detectiontui_gateway/server.py—clipboard.pasteRPC methodProposed Fix
Detect GNOME Terminal via
GNOME_TERMINAL_SERVICEorVTE_VERSIONenvironment variables, and skip OSC52 in favor of native clipboard tools:Logs
01-hermes-debug-output.txt
02-system-env-diagnostics.txt
04-issue-body.txt
README.txt
Tags