Skip to content

Reject duplicate pasted images by content hash - #420

Merged
TheGreatAxios merged 4 commits into
mainfrom
cl-5734-reject-duplicate-pasted-images-by-content-hash
Aug 8, 2026
Merged

Reject duplicate pasted images by content hash#420
TheGreatAxios merged 4 commits into
mainfrom
cl-5734-reject-duplicate-pasted-images-by-content-hash

Conversation

@TheGreatAxios

Copy link
Copy Markdown
Collaborator

Summary

  • Pressing the paste-image shortcut on an unchanged clipboard no longer stacks up duplicate attachments; the decoded image bytes are hashed and compared against the pending set before the image is added.
  • A repeat paste of an already-attached image flashes a clear status message instead of silently attaching (or silently doing nothing).
  • Genuinely different images, and the same image re-pasted after the pending set is cleared, attach normally.

Test plan

  • bun run typecheck
  • bun run build
  • bun run test

Repeated presses of the paste-image shortcut on an unchanged
clipboard should not add a second copy of the same screenshot, but
nothing currently compares attachments by content, so identical
pastes stack up unbounded. Also carries the content hash onto
PendingImageAttachment so the test can express identical bytes
independent of filename or id.
The clipboard is read into a timestamped file every time, so
filename gave no identity to dedupe against and an unchanged
clipboard produced unlimited distinct attachments -- an operator
hit eleven copies of one screenshot. Comparing the SHA-256 of the
decoded bytes against the pending set before adding catches an
identical re-paste while leaving genuinely different images
untouched, and flashes a clear "already attached" message instead
of failing silently.
PendingImageAttachment now always carries a contentHash, so every
test fixture that built one by hand needs a value too, and the
SHA-256 digest call needs a plain ArrayBuffer-backed view to satisfy
BufferSource's type.
@linear-code

linear-code Bot commented Aug 8, 2026

Copy link
Copy Markdown

CL-5734

…he hash source

The rejection flash was reporting the rejected paste's own name, which
the operator never saw -- every clipboard read gets a fresh
clipboard-<timestamp>.png, so the message pointed at a filename that
didn't match the chip already in their prompt. Report the attachment
already in the pending set instead.

Also add a producer-level test against imageAttachmentFromPath with an
oversized fixture, so the pre-cap hashing is pinned by more than the
comment above it; make the hash helper module-private since nothing
outside this file needs it.
@TheGreatAxios
TheGreatAxios merged commit 8addf44 into main Aug 8, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant