Clipboard file-list reads and writes ran on background threads, while AppKit and WebKit use the general pasteboard on the main thread. Its type cache isn't safe against that, so the app crashed with a segfault or heap corruption in `-[NSPasteboard _updateTypeCacheIfNeeded]`. Rechecking the clipboard on window focus made this frequent, sometimes within seconds of opening a project.
On macOS these commands now run on the main thread and await the result without blocking a command thread; other platforms are unchanged. `ide-clipboard` documents and debug-asserts the requirement. A concurrent read stress test that crashed main within a second completed about 650,000 reads over four minutes with no crash.
Project Paste could reuse an earlier file copy after another app replaced the OS clipboard, and Cut files stayed dimmed. The tree now tracks the hand-off to the OS clipboard and rechecks it on window focus and just before Paste. A local Copy or Cut is cleared once the OS holds a different or empty file list; failed writes and clipboard read errors keep it. The native adapters now distinguish read failures from empty lists.
In remote windows, Copy and Cut write newline-joined server paths as plain text, tree Paste keeps the server source, and a later OS file list replaces the remote copy and imports those client files. A plain-text replacement stays undetectable there without a clipboard read that may prompt.
Verified on macOS, locally and against a remote host. The Windows clipboard code was not run.
Copying files in the project view wrote only the file list to the OS clipboard, so pasting into an editor did nothing. The copy now also writes the newline-separated paths as text, which other applications can paste.
WKWebView hides that text when file URLs are present and delivers a paste event with only Files, so the IDE editor and terminal still received nothing. A shared helper now reads the OS file list when a paste has files but no text, and inserts the paths. It covers Cmd+V and context-menu Paste in the editor, the terminal and embedded terminals. Markdown image paste runs first and keeps its behaviour.
Verified on macOS. The Windows clipboard change was tested by the contributor at the clipboard level only.
Refs #573
Co-authored-by: a-rookie-of-C-language <186315048+a-rookie-of-C-language@users.noreply.github.com>
The OS clipboard's file list was only wired up for Windows (CF_HDROP), so on
macOS the project view never saw files copied in Finder: Paste stayed disabled
and ⌘V did nothing. Read and write the general NSPasteboard's file URLs
instead, so Finder's copies paste into the project view and the project view's
copies paste in Finder.
Closes#246
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Exchange files with the OS clipboard on Windows: CF_HDROP read/write in a new ide-clipboard crate (Win32 FFI behind cfg(windows), stub elsewhere), three thin commands, and project-view copy/paste hooks. Pasting from Explorer always copies; our own hand-off falls back to the internal clipboard so Copy/Move dialogs and refactoring stay intact.
Verified: ide-clipboard round-trip tests, project-tree vitest (93), CI on all three OSes. Not verified on Windows hardware here.
Claude-Session: https://claude.ai/code/session_01VUYsdXA2nkF5v6zsC93dpn
l0ng-ai
arookieofcanda-rookie-of-C-language
JawandClaude Opus 5.5
kevinh