Unless you're good at actually maintaining your gpg keychain and need other people to access this, I really wouldn't bother with gpg. There are way better and simpler options.
direnv can support any cli secrets manager per project directory https://direnv.net/
I've dealt with enough "why did this break" situations with gpg secrets files used by capable teams that I'd never recommend that to anyone. And unless you really need the public key support (teams and deployment support), you're unlikely to gain anything better over a password manager.
Age doesn't even have a keychain. You are expected to maintain your keys manually. So yeah, you will never have a problem with the age keychain. In the same way you will never get into trouble with the law in an anarchy. Not everyone wants to have to deal with all the details themselves.
age looks really interesting, thanks. I also learned from that page that appending ".keys" to your GitHub profile URL (so https://github.com/yourusername.keys) returns a list of your SSH public keys! (Where is this documented...?)
Oh - so age would be a gpg replacement, and not a shell-secrets replacement. I guess it could work, but also I haven't had any issues with GPG yet (in my ~4 years regularly using shell-secrets).
ejson2env sounds nice. Don't like the syntax of `eval $(...)`, but it does THE thing that most don't - it encrypts the secrets at rest!
Also, I have multiple logins for some services (company account vs company's client account), so separating concerns is cool. And having the "context" name in the PS1 helps avoid issuing the wrong command on the wrong account - you can even add emojis to the name for maximum discernability.
What happens when you have multiple matching keys? What happens when your key expires? What happens when the output format changes? What happens when the key expires and it's attached to a hardware device? Gpg can fail in ways which do not tell you anything about the real underlying issue.
I promise this happens all the time to people for lots of stupid reasons.
They're not unusable, but depending on the gpg wrapper it may look like it. Gpgme is the one I had most issues with raining with fatal errors where gpg on its own only reports a warning.
Non of this is impossible to overcome. Yet, I still was sometimes relied on to debug things.
Gonna have to give that a try because it sounds like a very bad interpretation of the expiry mechanism in keys - encryption functionally never expires if you have the key, because you have the key. It's solely an error on the part of the sender to use an expired key, because it might be no longer available.
(admittedly AFAIK encryption is handled by key expiry poorly overall in GPG - the lack of perfect forward secrecy means an expired key which leaks can still decrypt all the old messages if they were intercepted).
Age has a simpler interface and SSH key support https://github.com/FiloSottile/age
ejson2env has the environment variable integration and ejson has multiple backends https://github.com/Shopify/ejson2env
direnv can support any cli secrets manager per project directory https://direnv.net/
I've dealt with enough "why did this break" situations with gpg secrets files used by capable teams that I'd never recommend that to anyone. And unless you really need the public key support (teams and deployment support), you're unlikely to gain anything better over a password manager.