Fix macOS multi-file copy to clipboard (#234) - #251
Conversation
…write on paste Two fixes for Slackadays#234: 1. Read back from NSPasteboard after writing multiple file URLs to work around a macOS bug where only the last item persists otherwise. 2. Skip writing GUI clipboard content into internal storage for non-write actions (paste, show, etc.) to prevent external apps from corrupting the clipboard entry between copy and paste operations. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
@mohammadazeemwani hi, this did work for me on both of my two macbooks: |
|
@happyTonakai OS: macOS Tahoe 26.3.1 arm64
Host: MacBook Air (M2, 2022)
Kernel: Darwin 25.3.0 |
|
I haven’t tested on macOS 26 and don't have a device for it, so this is probably an OS compatibility issue. Maybe some behavior is not the same on macOS 26. |
Replace the readObjectsForClasses workaround with NSPasteboardItem, which explicitly sets NSPasteboardTypeFileURL for each file. This avoids the immediate read-back hack that may trigger macOS 26's new pasteboard privacy protections. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
@mohammadazeemwani I think I found the cause. The previous fix used I've replaced it with Could you pull the latest and test again? |
|
I build the project again after pulling latest changes and results still the same:
I am on this commit: 3a0ecd1 |





Summary
cb pasteoutputting text instead of files when external apps overwrite the system clipboard between copy and pasteProblem 1: Multiple files not preserved on macOS
macOS has a bug where
NSPasteboard.writeObjects:only retains the last item when writing multiple file URLs. This causedcb copy file1 file2 file3to only preserve one file on the system clipboard.Fix: Read back from the pasteboard immediately after writing with
readObjectsForClasses:, which forces macOS to internalize all written items.The fix is based on a workaround shared by timhansinger in #234, who encountered the same macOS pasteboard bug in their own tool pbcp and solved it with the same read-back approach (implemented in Swift). The technique translates directly to our Objective-C++ code since both use the same
NSPasteboardAPI.Problem 2:
cb pasteoutputs text instead of filesWhile testing Problem 1 over SSH, we discovered that
cb pastewould output shell command text (from the terminal's OSC 52 response) instead of the copied files. The root cause:syncWithExternalClipboards()was called at the start of everycbinvocation, including paste/show. It would read whatever was on the system clipboard (which other apps like the terminal may have overwritten) and write it as a new clipboard entry viaconvertFromGUIClipboard(), effectively replacing the file entry with a text entry.Fix: Skip calling
convertFromGUIClipboard()for non-write actions (paste, show, etc.) since these operations should only read from internal storage, not ingest whatever is currently on the system clipboard.