Repository navigation
feat: save the clipboard image's original bytes with desktop_clipboard_read save_path - #96
Merged
Merged
Conversation
iamnbutler
force-pushed
the
feat/clipboard-image-save
branch
from
October 17, 2026 07:45
89c2c3b to
81642b2
Compare
This was referenced Oct 17, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Image export for #3. Temporary image and file paste are out of scope; that needs the reservation design.
How
peekaboo-clipboard-image-export.patch, last in the stack. It adds a read-onlyclipboardImageExportBridge op.readImageas the existing read: the same silent-read gate, one-item and generation checks, and PNG/JPEG/TIFF validation within 10 MiB.ClipboardImageContents.original, which stays nil for an ordinary read..clipboardImageExport. The original bytes stay behind the host gate; the client never reads the pasteboard itself.export_pathon image reads. It writes the original bytes to that new file (without overwriting) and drops them from the reply. The reply stays well under the 2 MB stdout limit, which 10 MiB of base64 wouldn't.desktop_clipboard_readtakessave_pathandoverwritewithformat: "image", following feat: save a screen or window capture as a full-resolution PNG, optionally one region #81's rules:overwriteis true, and a symlink or folder is never replaced.overwriteis set..png,.jpg/.jpeg,.tif/.tiff. On a mismatch nothing is written, and the refusal names the type to use.savedreturns path, UTI, MIME type, bytes, width and height.saved: nulland writes nothing.regionis refused.save_pathandoverwriteon text or files reads are refused.Tests
PeekabooBridgeRequestPlanTests|PeekabooBridgeOperationSemanticPlanTests|PeekabooBridgeOperationResultSemanticsTests, 72 passed.readImageitself, since it needs the real pasteboard. I didn't add one that would touch the user's clipboard.npm test: 39 pass. A new test covers the extension rules per type, byte-for-byte copy, refusal of an existing file withoutoverwrite,overwrite, and an incomplete export.npm run checkis clean, and the native build with the full stack passes.Live check: pending, screen locked. Copy a PNG and a JPEG (for example from Preview), save each with a matching path,
cmpagainst the source, then try a mismatched extension. I'll add this to #42.