[monsterlag]

Note

AI-generated, not reviewed by a human. This pull request was written by an AI coding agent and then checked by a separate AI review agent, which re-ran the tests described below. No human has reviewed the code. It is submitted by @monsterlag, who runs these agents. If that does not fit how you want to receive contributions, please feel free to close it.

Fixes #824

What was wrong

AppState.copyPath(xcode:) called declareTypes([.URL, .string], owner: nil), then writeObjects([url as NSURL]), then setString(_:forType: .string). That leaves two pasteboard items:

item	types	data
0	public.url, public.utf8-plain-text	public.url is declared but never provided (nil); the text is the path
1	public.file-url	file:///Applications/Xcode%2026.0.app

pbpaste still finds the plain text, but apps that read the first item's URL type find no data. That matches the report: Terminal and Pasteboard Viewer paste nothing.

How it is fixed

copyPath now clears the pasteboard and writes a single NSPasteboardItem that carries both the plain-text path (.string) and the file URL (.fileURL). Both types have real data. It also takes an optional pasteboard parameter, defaulting to .general, so a test can use a private pasteboard.

copyReleaseNote(from:) writes the pasteboard in the same way and may have the same problem. I left it alone to keep this change scoped to the issue.

How it was tested

The tests ran on macOS 26.6 with Xcode 27.1:

• New test AppStateTests.test_CopyPath_WritesOneItemWithPathAndFileURL uses a uniquely named NSPasteboard. It checks for exactly one item that holds the path and the file URL, using an app path that contains a space.
• With the old pasteboard code (only the pasteboard parameter injected), xcodebuild test -scheme Xcodes -destination "platform=macOS" -only-testing:XcodesTests/AppStateTests failed only the new test, with 3 assertion failures. The item count was 2, the first item's types were public.url, public.utf8-plain-text, and the file URL was nil.
• With the fix, xcodebuild test -scheme Xcodes -destination "platform=macOS" (the CI command) passed: Executed 52 tests, with 0 failures, ** TEST SUCCEEDED **.

Pasting was checked in a macOS 26.6 desktop session (Cmd+V sent through System Events): with the old code Terminal pastes nothing, which reproduces the issue; with the fix Terminal pastes the shell-escaped path (/Users/admin/pbtest/Xcode\ 26.0.app , the same as dropping the file), and pbpaste gives the plain path.

One behaviour change: rich-text TextEdit now inserts a file attachment instead of the path text. The new layout is the same one Finder's own Copy as Pathname (Option-Command-C) writes on macOS 26.6 (one item with public.file-url and public.utf8-plain-text). If you'd rather have plain text everywhere, a single item with .URL plus .string also fixes the issue (Terminal and TextEdit then both get the unescaped path); happy to switch to that.