Why a copied image file breaks too
Copy a PNG in Finder and the clipboard does not receive an image. It receives a file URL, a path string pointing at the original. Every preview and every paste then depends on that file still being where it was, still named what it was named, and still readable.
Under App Sandbox, that last condition is the one that fails. An app gets access to a file through the copy event, and that access does not automatically survive a relaunch. The path is still in the database and the file is still on disk, and the app can no longer open it.
The bytes being on disk is what makes everything else on an image possible later. Text recognition runs at paste time, on the stored image, so a screenshot from three weeks ago still reads.
Storage is deduplicated by content hash. Copy the same screenshot four times, in four different apps, and one copy of those bytes exists on disk. Copying a large image also does its hashing and writing off the main thread, so the paste you are in the middle of does not stall.
What Klipto does instead
Klipto reads the image bytes at the moment you copy, while the pasteboard access is still valid, and writes them into a local store keyed by a SHA-256 hash of the content. The database row points at that file. Nothing depends on your original screenshot staying put, so previews and pastes work after a restart, and after you rename or delete the file.
I spent a full day on this and it was harder than it looks. Image bytes cannot go inline into the database, because SwiftData's external-storage attribute crashes when you touch a detached object during a delete. So the store is hand-written: hash, write, deduplicate, sweep orphans at launch.
One honest gap. Snippets and saved Stack items still keep image data inline in the database rather than in that store. They survive a restart, which is the part that matters here, but they do not get the deduplication. That is on the list.
The trap: a thumbnail is not the image
Some tools keep a small preview and drop the original. The history row looks fine, then the paste comes out at 240 pixels wide or does not come out at all. Klipto stores full bytes, so what you paste is what you copied.
The other quiet failure is retention. History has limits you set yourself: a number of items, an age in days, a size in megabytes. A screenshot from four months ago is gone because you told the app to remove it, not because storage broke.
What I use
Klipto for anything I might want twice, which is most reference screenshots. For a single image I am definitely keeping, ⇧⌘4 and a real file in a real folder is still the correct answer, and it costs nothing.
Klipto began on Maccy's open-source core and has gone its own way since. Persistent image storage, and the recognition that rides on it, is one of the places it went.