v0.11.0

What's New in v0.11.0

Copying out of a remote session now works without you asking it to, Windows paste works in the terminals where it silently did nothing, and Cursor finally tells you when it is done.

Copy on the remote, paste on your machine — no command to remember

v0.10.0 gave you cc-clip copy as an explicit pipe. That was the wrong shape: copying in a remote session does not happen through pipes. You yank in neovim, you hit Enter in tmux copy-mode, you use a TUI's copy action — and all of those invoke xclip or wl-copy, which the shim already sits in front of.

So it now just happens:

" in neovim on the remote
set clipboard=unnamedplus     " y / yy / p now cross the SSH boundary

# in tmux on the remote
set -g set-clipboard off
bind -T copy-mode-vi Enter send -X copy-pipe-and-cancel 'xclip -selection clipboard -i'

The write is forwarded through the tunnel to your local clipboard and replayed into the remote's real xclip, so the remote clipboard behaves exactly as before. Either side succeeding is enough — headless remotes with no real xclip still work. Bytes are verbatim: no terminal rendering is involved, so nothing is soft-wrapped or mangled.

cc-clip copy remains the explicit primitive for pipes. docs/reverse-copy.md covers both configurations and states the boundary honestly: a mouse selection in your local terminal copies what the terminal rendered, no SSH-side process observes it, and no version of cc-clip changes that.

Windows: the paste that reported success and did nothing (#140)

On Electron-based terminals — Wave, Hyper, Tabby, VS Code's integrated terminal — the auto-paste was silently dropped. The upload landed, hotkey.log said send completed, the tray said Image pasted to <host>, the focus guard logged no abort, and the terminal received nothing at all. The keystroke went out through WinForms SendKeys, which Chromium windows ignore outright while SendWait still returns success.

The keystroke is now delivered with SendInput, which those terminals accept, and which reports how many events the input stream actually took — so a refusal (a window running as administrator, for instance) is an error instead of a silent success. It also releases a physically-held ALT/WIN first, so the modifiers of the triggering hotkey no longer merge into the chord.

Two more fixes on the same path:

cc-clip hotkey myserver --no-restore

--no-restore was available on send --paste but not on hotkey. It leaves the remote path on the clipboard instead of putting the image back 150 ms later, so on any terminal that still drops synthetic input your own Ctrl+V pastes the right thing. It persists as "no_restore": true in hotkey.json, so it survives the autostart launcher and a reboot.

And cc-clip hotkey --status no longer reports "not running" for a loop that is plainly alive. It identified the process by asking PowerShell for Win32_Process.CommandLine and treated every failure of that lookup — including the empty result you get without rights to read it — as "not our process", then deleted the PID file. One unreadable reading lost the PID permanently: --status said "not running" forever afterwards and --stop could no longer stop the process. Identity now comes from the process image path, and the probe distinguishes gone / not ours / could not tell, reporting the third instead of claiming the loop is down.

Thanks to @Song100Years for a report that diagnosed all three correctly, including the detail that SendWait returns success regardless — which is what made the first one findable at all.

Cursor CLI notifications (#109)

cc-clip connect myserver --cursor

--cursor shipped clipboard support in v0.10.0; it now installs a notify hook too, merged into ~/.cursor/hooks.json. Your own hooks in that file are preserved — the stop event keeps every command that is not ours, and a file that will not parse is refused rather than overwritten.

cc-clip doctor covers the notification bridge (#22)

doctor previously stopped at the clipboard path. It now checks the notify nonce, the hook wiring, and the delivery chain, so "notifications stopped working" is a diagnosable state rather than a guess.

Other Improvements

• Windows is now built and tested in CI. checks.yml ran only on ubuntu-latest, which compiles none of the //go:build windows files — the hotkey loop, the tray, every clipboard writer and all of their tests were invisible to every gate, and a break surfaced only when goreleaser cross-compiled at tag time. That is the actual reason the three bugs above shipped. There is now a cross-build + vet step for windows/darwin on both arches, a windows-latest test job, and a gofmt gate.
• staticcheck is pinned. It was invoked as @latest against a pinned toolchain; when staticcheck raised its own Go floor, CI went red on commits that had changed nothing.
• main.go split into connect.go / notify.go / serve.go (#20).
• Docs: docs/reverse-copy.md is new; docs/commands.md gains the --cursor row it never had; the zh/ja READMEs mirror the v0.10.0 feature set.
• The daemon no longer prefixes its own clipboard-write notification with [unverified]. That marker means "this text came from somewhere the daemon cannot vouch for"; spending it on a message the daemon wrote itself is how it stops meaning anything.

Upgrade

Local machine first, then each remote host.

# macOS / Linux, existing install
cc-clip update

# macOS / Linux, fresh install
curl -fsSL https://raw.githubusercontent.com/ShunmeiCho/cc-clip/main/scripts/install.sh | bash

# Windows, install or upgrade
irm https://raw.githubusercontent.com/ShunmeiCho/cc-clip/main/scripts/install.ps1 | iex

Then, for every remote host:

cc-clip connect <host> --force

The reverse-copy write shim and the Cursor notify hook are both installed by connect; without this step the remote keeps the old shim and nothing above changes for that host.

Windows users on the hotkey path should re-run cc-clip hotkey <host> --enable-autostart so the loop restarts on the new binary.

Not in This Release

• The Windows paste fix is not verified on real hardware. There is no Windows machine behind this release. The new windows-latest job runs the Windows-only unit tests for the first time, but whether SendInput actually pastes into Wave is unconfirmed — please report on #140 either way. If it still does nothing for you, --no-restore is the fallback that works regardless.
• Cursor notifications are not verified against a real cursor-agent. Cursor's CLI hook support has a history of firing unevenly, and cc-clip records this adapter as installed-but-unverified for that reason. Reports welcome on #109.
• Mouse selection in your local terminal still does not reverse-copy, and cannot — see docs/reverse-copy.md for why and for the two configurations that do work.
• Reverse image copy is still unimplemented (#128); no motivating case yet.
• Persistent per-host SSH tunnels (#108) and notification icon/sound settings (#92) remain open.

Verification

V=0.11.0
gh release download "v$V" --repo ShunmeiCho/cc-clip \
  --pattern "cc-clip_${V}_darwin_arm64.tar.gz" --pattern "checksums.txt"
shasum -a 256 -c checksums.txt --ignore-missing

Full Commit List

• 98f2add feat(notify): Cursor CLI notifications via ~/.cursor/hooks.json (#109)
• 41f6c5e docs: --no-restore does not stop the keystroke, it makes it optional
• fa172c4 docs: reverse-copy guide, and stop labelling our own notification unverified (#128)
• 9f083a6 fix(windows): deliver paste with SendInput, add hotkey --no-restore, stop losing the PID file (#140)
• 906bba1 feat(shim): transparent reverse copy — clipboard writes land locally (#128 phase 2)
• 6ed1699 docs(i18n): mirror v0.10.0 features to zh/ja READMEs
• 7694090 docs: README tagline covers Cursor and reverse copy
• 7b477fb feat(doctor): cover the notification bridge (#22 P1)
• 041fbce refactor: split main.go into connect.go / notify.go / serve.go (#20 I1)

Full diff: v0.10.0...v0.11.0