What exactly is your threat model, where the attacker can read ~/.bash_history but can't execute (or capture output from) /usr/bin/env?

CI and other build systems. Where tokens have been stolen in the past, by users not caring, and a VM not being properly cleaned.

The threat model is that history is persistent while the environment isn't. That said, whenever possible you should handle secrets using file descriptors as opposed to environment variables.

How about not accidentally showing tokens and credentials when live screen sharing?

You do NOT save passwords in shell history, it is insanely insecure. Lets begin with the passwords being readable by everything that can list tasks.

You can protect passwords in a password manager. You do not need to keep the passwords in env and I do not.

> Lets begin with the passwords being readable by everything that can list tasks.

Why are processes running that can do this, that I don't already fully trust?

> You can protect passwords in a password manager.

What's your plan for supplying the password to the program, given that people will want to automate use of the program?

Threat model: shell scripts