1Password on Mastodon

op get item also looks in Trash

Community Member

One of my scripts looks up a document (an encrypted ZIP file) by its title. jq extracts the password field I added to that document (via the GUI).
When I tried to decrypt my (local) file with the looked up password, it failed. Turns out, there was a older document with the same title (but with a different password) in 1P Trash.
IMO the CLI should either return all matching entries when looking up by name (instead of UUID) or issue a warning when the lookup is ambiguous. In this special case, one might argue the Trash should not be searched at all (this could also be flagged with something like an --include-trash parameter to be really fancy ;)).

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided


  • Yea, I have to say that I'm not crazy about how we handle cases of multiple matches. It almost feels like "op get item" should require an item uuid, but then we'd have to require the vault uuid/name too cause item uuid alone isn't sufficient for uniqueness.

    I think we should consider making "op get item" not look in the trash and add a flag to enable looking in the trash.


  • cohixcohix
    1Password Alumni

    @dschneller Thanks for the feedback! I'm also not too happy with the behavior. We have an --include-trash flag on the op list items command, but not on op get items. I think it makes sense to ignore trashed items when getting an item by title, but for now I would suggest using the item's UUID for this purpose.

    I think I agree with @rickfillion that get item should take a UUID and then we could possibly have an op search item that returns multiple results? Food for thought. Let me know what you think would work for you :)

  • dschnellerdschneller
    Community Member
    edited October 2017

    The UUID based get would make things easier technically, of course. If the search call was split out, so I would get a list of one or a few entries matching my criteria -- especially the name, but maybe others -- that would be perfectly fine. In a second step I could then get the item by ID. Also, either provide the --include-trash or at least surface the information about whether an item is trashed in the result.

    Also: Please consider not only op search item then, but also op search document. One of our most relevant use cases involves uploading a document and adding a password field to it. Currenly list documents only returns IDs, not even the title, let alone any other fields. If need be, I could, of course, add a separate Password item and link that to the document, but that would IMO needlessly increase the number of vault entries.

  • cohixcohix
    1Password Alumni

    @dschneller You're absolutely right about that :) We'll keep this feedback in mind going forward. Please let us know of any other gripes you may have!

This discussion has been closed.