FWIW: Okay, gmime is still a wrapper around gpgme. After decryption it has the ability to get the used session key from the gpgme result structure. Thus, I have been on the wrong trail. The actual problem is not gpgme but more GnuPG's use of Libgcrypt or an actual regression in Libgcrypt. Well, Friday 13th.

Any hints where to find the actual crypto code which uses libgcrypt?

Maintainer of the FreeBSD notmuch port/package here. The steps below consistently trigger the problem on FreeBSD 16.0 (unreleased main branch), but there are no problems on FreeBSD 15.0. All my testing was on amd64.

Any hints where to find the actual crypto code which uses libgcrypt?

@thesamesam Thanks a lot.
I managed to replicate the failure somehow (for me, it fails at the importing the key).

I've attached notmuch-bug.log with debug-level guru commented out for gpg-agent:

I can reproduce it using Stuart's script from https://lists.gnupg.org/pipermail/gcrypt-devel/2026-February/006031.html.

Please tell us the information of your environment.
What the versions of gpg and gpg-agent?

Additionally to the fix Andre cited years ago, we also did some more changes recently in regard to how signed/encrypted mails are shown. Which are relevant for the inbox, too.
This issue should be fixed.

Hi, I've managed to reproduce this bug on the gpg4win-5 beta as well. I think the frequency has gone down, perhaps, but it is still present.

As there has been no more feedback on this for years, I'll close this.

If this is indeed a bug it won't be fixed in gpg4win 4. Thus a test with gpg4win 5 beta is highly appreciated. It would also be interesting to see what what version of gpg comes with Git.