Prefixing this with saying that I agree the UX on this is not great and could definitely be improved both from a usability standpoint and a security standpoint.

Prefixing this with saying that I agree the UX on this is not great and could definitely be improved both from a usability standpoint and a security standpoint. That said: The actual reality where someone gets their password stolen because they used 1Password's ClI tool seems pretty hard to run across. You have to have something running _at the exact moment_ when you're running this tool (and I imagine it shouldn't be running for very long) that also manages to harvest the entire set of running processes and their arguments. Said something then has to also transmit this information to a third-party server AND that third-party server has to be looking for this specific CLI tool in the hopes of catching it running. Zoom is unlikely to manage to grab a list of processes at the same time that you're using this CLI tool (because it will be doing this on some internal timer or at the time when you are selecting something to share, and you have to be using it while using Zoom which should be a less-frequent occurrence due to generally paying attention to the call). And on top of that, if they even submit this information to their servers, I highly doubt they're going around deliberately scanning for passwords to maliciously use since they're a company focused on teleconferencing and not black hat activities. And even beyond that this should still be more secure than a common alternative I've run into (and have done myself, because convenience was more important to me than 100% security at those jobs) where developers are just storing passwords and tokens in plain text in a bash/zsh rc file. That's a pretty easy target for a more realistic case of a module on something like NPM gaining some malicious code that checks some common files and patterns (e.g.: a line including export, PASSWORD, and =) and harvests that data to send to a malicious server. And again, I'm not saying this is _good_, it's definitely not. I'm just saying that the case where this is actually exploited is pretty slim, bordering on not going to actually happen even if something just so happens to harvest that command running and sends it to their servers. Because it's much more likely that the thing harvesting that info isn't interested in stealing your password. There are much easier targets for malicious code to go after.