Troubleshooting

User-facing symptom → cause → fix, for the questions that keep coming back. One section per symptom; keep entries short and command-exact.

Copy from the embedded terminal doesn't reach my clipboard (especially over SSH)

How copy works. kobe's embedded terminal is a full-mouse TUI: it enables the terminal's mouse reporting (clicks focus panes, tabs are clickable, the wheel routes to the app). Mouse reporting hands drag-selection to kobe, so your terminal emulator's native selection no longer participates. Every mouse-enabled TUI (tmux, vim with mouse=a) makes the same trade. kobe implements its own grid selection instead: drag to select (pane-aware, works inside splits), release to copy. Delivery is dual-channel:

1. a pipe into the platform clipboard command on the machine kobe runs on (pbcopy / wl-copy / xclip / xsel), and
2. an OSC52 escape sequence written to the tty.

The SSH case. When you SSH into the machine running kobe, channel 1 lands on the remote machine's clipboard, not yours. The only channel that can reach the clipboard of the machine you are physically at is OSC52: it travels back through the SSH tty and is executed by your local terminal emulator.

kobe (remote) ──OSC52──▶ ssh tty ──▶ your terminal app ──▶ your clipboard

So if copy "works locally but not over SSH", the break is almost always at the receiving terminal app (the one drawing pixels in front of you):

tmux in the path? If kobe itself runs inside a remote tmux session, tmux swallows OSC52 unless told to forward it:

set -g set-clipboard on

Escape hatch that always works: hold Option (macOS) / Shift (most Linux terminals) while dragging. That bypasses mouse reporting entirely and uses your terminal's native local selection + copy, which always lands on your local clipboard, at the cost of selecting across the whole kobe window (no pane awareness), exactly like tmux.

Remote workflows: the kobe web dashboard sidesteps all of this. The browser owns the clipboard.

Mouse wheel in the embedded terminal

The wheel follows real terminal-emulator semantics, in order:

1. the embedded app enabled mouse tracking (claude's transcript, vim, less --mouse) → the wheel is forwarded; the app scrolls itself;
2. fullscreen app without mouse tracking → 3 arrow keys per tick;
3. plain shell → kobe's local scrollback (same channel as ctrl+pgup / ctrl+pgdn; scroll to the bottom to resume following).

If scrolling "does nothing" inside an app, that app received the events and chose not to scroll. Check its own mouse setting (e.g. :set mouse=a).

Memory stays high after upgrading from a pre-0.8 build

kobe 0.8 replaced the old tmux runtime with the PureTUI + Hosted PTY backend, but upgrading the package does not stop sessions that a pre-0.8 build already left running. Those old tmux -L kobe sessions keep their bun / engine process groups resident, so memory can look unchanged after the upgrade.

kobe doctor now reports them:

legacy tmux: ⚠ tmux 3.5a — 2 pre-v0.8 session(s) on `kobe`
             20 process(es) across 8 pane(s), 1008.5 MB RSS total
             → run `kobe reset` to stop this retired runtime safely

Fix: kobe reset. It stops the daemon and Hosted PTY host, then SIGTERMs each legacy pane process group before killing the retired tmux server (a bare tmux kill-server would leak engines that ignore SIGHUP). Worktrees and the task index are untouched; add --hard only if you also want to wipe task/UI state.