Match Linux terminal copy/paste behavior

[joshdoe]

Summary

• align terminal copy/paste behavior on Linux with the expected platform flow
• left-drag selects, right-click when selection is present clears the selection, right-click with no selection pastes
• wire the Electron and preload IPC needed for the updated terminal clipboard path
• update the terminal view to use the platform-specific handling

[johannesjo]

Thank you very much for this and sorry for the late reply. Somehow I wasn't receiving notifications for PRs opened here. Could you have a look at the conflicts please?

[johannesjo]

Code Review

Overall: Well-structured PR that correctly solves a real Linux clipboard limitation. Routing clipboard through Electron IPC is the right call — browser navigator.clipboard can't access the X11 selection buffer. Clean implementation, proper cleanup, good test coverage on the backend.

---

Important

1. Needs rebase — merge conflict on register.ts line 1
Main now imports Notification from electron (from 587fde6). This PR changes the same line, so it will conflict. Resolved import should be:

import { ipcMain, dialog, shell, app, BrowserWindow, Notification, clipboard } from 'electron';

2. Incomplete test mocks in register.test.ts
After rebase, the electron mock will need Notification. Also missing from mocks: getAllFileDiffs/getAllFileDiffsFromBranch in git.js, and plans.js exports stopAllPlanWatchers but register.ts imports stopPlanWatcher (singular) + readPlanForWorktree.

3. pasteClipboard silently swallows errors

.catch(() => {});

A console.warn would help debug clipboard failures across Linux DEs (GNOME, KDE, Wayland, X11).

4. Unrelated test removal in pty.test.ts
The "bare command found in PATH" test deletion is unrelated to clipboard work — should be a separate commit.

5. ClipboardWrite with target: 'selection' on non-Linux writes nothing

if (target !== 'selection') clipboard.writeText(args.text);  // skipped
if ((target === 'selection' || target === 'both') && process.platform === 'linux') {  // skipped on macOS

Dead path today (frontend only sends 'both' or 'clipboard'), but worth either falling back to the default clipboard or throwing on unsupported platform+target combos.

---

Minor

• The requestAnimationFrame in handleContextMenu could use a brief comment explaining why the deferral is needed (letting browser finalize selection after right-click).
• Missing test cases: ClipboardWrite with explicit 'clipboard' target, ClipboardRead with no target, ClipboardWrite with 'selection' on non-Linux.