1Password CLI is fussy about TTYs

I upgraded from 2.0 to 2.5 of the CLI this week and it broke the iTerm2 integration. The issue seems to be that the CLI really cares about whether stdin is a tty or not.

These commands fail to open a biometric auth window when stdin is not a TTY and simply seem to hang:

• op user get --me
• op item create --category=login--title="whatever" --tags="whatever" --generate-password --format=json username="whatever"

While this command doesn't work at all when stdin is a TTY:

• op item get --format=json --no-color -

For some reason I don't understand, I can't reproduce this from a regular shell (.e.g, op user get --me < /dev/null does show an auth window) but when my Cocoa app forks & execs op user get --me with a pipe for file descriptor 0 it does hang, while giving it the slave side of a pseudoterminal doesn't hang.

Is this intentional? I'm a little worried that I may have missed some cases where the TTYness of fd 0 is wrong. It would be nice if op didn't care so much about this.

If there's a good reason for requiring a TTY in general, it would be nice if if providing a TTY didn't break anything. I don't see a good reason why op item get --format=json --no-color - should fail with a TTY, and the error it gives is not great:

[ERROR] 2022/07/06 23:28:40 "-" isn't an item. Specify the item with its UUID, name, or domain.

Thanks!

---

1Password Version: 8.8.0
Extension Version: Not Provided
OS Version: macOS 12.4
Browser:_ Not Provided