does CLI support beta feature Item sharing: send a copy of an item to a team member?

I understand there may be some reluctance to spread support for item sharing too broadly because you may be evolving better ways to handle this problem, but item sharing could be vastly more useful and secure for us if we could invoke it from the CLI so we could build automated processes around it that do not involve human admin staff

I am wondering if the CLI tool currently supports item sharing, and if not, are you willing to add it as beta functionality until there is a better way?

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


  • ag_yaronag_yaron

    Team Member

    Hey @paulpharr ,

    Can you please elaborate on how/why/when you'd like to share an item via the CLI? More details here would definitely help understand the use case and if this can/should be implemented :)

  • ag_yaronag_yaron

    Team Member

    @paulpharr Perhaps you mean the --share-link flag?

    For example: op get item [item name/UID] --share-link?

    The items link is basically this feature:
    And it is also mentioned in the CLI docs:

  • Hi Ag,

    It's not sharing links - it's the send item functionality described here:

    We want to be able to create a new secure item or document, then send it to a user using the CLI, then delete it.

    An example use case is if, for example, we wanted to automatically generate a VPN certificate during our new employee onboarding process and send it from an administrative 1password account directly into the new employee's 1password vault. We can do this now in the web GUI using your beta feature, but since it needs to be done by a human, the employee needs to trust not only the system, but the human who sent it.

    If we could automate the process of creating this certificate, we could send it to the new employee and destroy it, so they are the only one who has it & no other human has ever seen it.

    Coincidentally, just a half an hour ago, another of your business users posted this question asking for exactly the same functionality for exactly the same reason:

    We have wanted this for a long time, but have never asked - primarily because it was not so important before COVID WFH. Now all of our new employee onboarding is remote & often new employees never even show up in an office. The ability to privately & securely send things straight to their 1password vault has huge benefits.



  • ag_yaronag_yaron

    Team Member

    Thanks for clarifying, Paul.

    This feature is not available in the CLI at the moment, but I'll definitely bring it up with the team and see if it can be added as a feature request!

  • Any chance of this becoming a feature some time soon? I agree with @paulpharr that it would be incredibly useful for exactly that use case, and it's kind of tedious to have to do it through the GUI en masse.

  • I have been watching the CLI version recently thinking it's time for an update. I think it's likely that this is not technically difficult to do in a secure way from the CLI and from my POV it has huge value in enabling new 1password use cases in our environment.

    For us it could enable some really difficult automated workflows that are manual now because of their security sensitivity.

    I will sheepishly admit I have even just hired someone with the expectation they will be able to work on some of these workflows in the next few months.

    Fingers crossed!

  • ag_yaronag_yaron

    Team Member
    edited January 25

    Thanks for checking in on this.
    We currently do not have immediate plans or timeline for this specific feature, but I'll let the team know more users are asking for it, which is great! :+1:

    ref: dev/b5/op#1116

  • edited January 28

    Seconded... or third'ed.

  • ag_anaag_ana

    Team Member


  • Hey @paulpharr, have you considered automation of a shared vault, adding the new member to that vault, along with HR if need be, adding the password to that vault, then after a set time autodelete?

  • paulpharrpaulpharr
    edited February 5

    To be honest, I had not thought of that. I believe I have the impression that vaults are not so lightweight and in the back of my mind I am worried that creating and deleting them potentially by the hundreds over time in our team account would run the risk of having side effects (performance, security, or otherwise).

    Nevertheless, thanks for the suggestion! It would accomplish my existing need, and I expect would be manageable in the short term. For that matter, I could create a 'company dropbox' vault for each employee that they were permanently connected with and use it for passing any credentials they needed.

    Having all those vaults in the GUI might be a pain for admins though.

    I wonder if my speculation on how I might abuse their system is giving the 1Password team indigestion?

  • ag_yaronag_yaron

    Team Member

    Thanks for the idea @Kennyties.

    I think you should give it a try @paulpharr and return with some feedback on it :)

  • You are very welcome @paulpharr. I can see how creating hundreds would strain the system. You could also look at the Secrets Management module. @ag_yaron no problem!

  • ag_yaronag_yaron

    Team Member


  • Hey @ag_yaron I do actually have a follow up question, I am trying to automate 1password but I am not sure how to get around the prompt for password. Is there some instructions on that or should I just send a task to the CLI every 20 minutes or so to keep it open?

  • ag_yaronag_yaron

    Team Member

    Hey @Kennyties ,

    You're not supposed to get around the password prompt :)
    You can either keep the session alive by sending a command every 29 minutes or less, or you can include the op signin command in your script with your Master Password, which I wouldn't recommend.

  • Hey @ag_yaron,

    That is a very valid point. I think my best bet is to work a manually login into my daily tasks.

  • ag_yaronag_yaron

    Team Member

    Sounds like the right way to go :+1:

  • paulpharrpaulpharr
    edited February 14

    I have had a chance to explore the proposed method of using a shared vault in order to pass secrets and credentials from our automated systems to individual users with no human intervention. All of the essential pieces are there, but there are a couple of rough edges I'll bring up here to get advice or maybe request adjustments in functionality.

    First I will say that from a user workflow point of view, we considered both creating these "handoff vaults" on demand and cleaning them up after the transaction as well as creating them and making them permanent for reuse as necessary. From the user point of view, we think a permanent one is better - making training easier & to avoid surprising the users. Having said that, we can probably make either approach work and most of the rough edges surround how to manage these vaults.

    Issue 1:

    The first issue, that's really more annoying than it sounds, is that 1pass seems to assign a (randomly chosen?) avatar icon to new vaults created by either the user or CLI. The user can at least adjust it if they notice it, but the CLI can't set it or edit it AFAICT.

    It seems from my experience that we are in for confusion if employees get requested credentials delivered into a vault with grandparents or airplanes, or cruise ships, or galaxys on their avatar icon. I would love to have the CLI just use a generic lock icon or allow the avatar to be specified during the OP CLI vault creation process.

    Even in the user vault creation GUI, the list of predefined icons for vaults has nothing generic. I'm all for entertaining icons, but I feel like when creating a new vault, there is rarely a good choice in the menu. Can we have just one generic lock? Or a custom option uploaded once & available to all users?


    If we create and maintain vaults for all staff, we will have several hundred that will be visible to the account owner (currently myself) and vault admins. We can live with this for now, but would really like to see some kind of mechanism that would allow us to tag these so they are hidden from most vault management contexts without making them inaccessible.

  • ag_yaronag_yaron

    Team Member
    edited February 15

    Hey @paulpharr ,
    Thank you kindly for the detailed feedback! I have forwarded it to the dev team.

    There are a couple of workarounds to the issues you wrote about straight from the top of my head though:

    • While the CLI can't assign vault icons, users (and you) can assign icons from the native desktop Mac app or via our web app. The default icon I use is the vault door icon. You can also upload your own icon if you'd like.

    • In the native desktop apps, you can also choose which vaults to show and which ones to hide, to make it easier to manage. Open the desktop app's preferences -> Vaults, and remove the check mark from each vault you don't want to show up in the app. You can do the same in the 1Password browser extension if needed.

    I hope you'll find this helpful for now.

  • Hi @ag_yaron

    thanks for your suggestions - I can work with what we've got right now. the biggest annoyance is the random vault icon for seemingly all vaults created by CLI. This is both annoying from an aesthetic POV and random behaviors from security focused software definitely sends the user the wrong message - this is one i'd love to see a resolution for.

    As an editorial comment, I will add that I love the focus on consistent brand design & user friendly imagery I see from 1pass. It extends from your public web, to your GUI, to your icons, to your blog - i really think it's great. Having paid you this well deserved complement, I will say that the vault icon you proposed above as a good generic security icon looks more like the wheel on a pirate ship to me than a bank vault - i want an option even more generic and boring for our automated systems to use :-)

  • We have started using the automated shared vaults process in our new employee onboarding process and it is working great. I see lots of opportunities and few problems other than those that have been discussed

    one small problem that feels like a bug, though im not sure:

    when we create logins using CLI, the password quality rating displayed by 1pass seems different that when the login is created by hand. The screenshot shows a record created by CLI with a 9 digit random alphanumeric login with upper and lower case. It shows the password quality as 'Terrible'. If I create the same record by hand, the password quality displays as 'Fair'

    not a huge deal, but for brand new users who are seeing 1password for the first time, I'd rather not be sending them passwords labeled as 'Terrible' by the system.

    In this case, the password is for their new machine login that they need to type by hand, and I really don't want it to be 20 characters long even if it did get around this problem. Is it possible that CLI created logins are always considered 'Terrible' password quality? Can this be improved?

  • ag_yaronag_yaron

    Team Member
    edited March 22

    Hey @paulpharr ,
    Thank you kindly for the additional feedback and kind words :)

    The issue with the password's strength was already fixed internally and should arrive to you in the next CLI update!

    ref: dev/b5/op#1099

  • I just switched to CLI 1.12.2 and the icon control is perfect - thanks for listening & keep up the good work!

    I can tell that 90% of the effort was coming up with all the names:

    art-supplies, green-backpack, large-ship, round-door, doughnut - LOL

    I see you gave up before four-person-family-with-glasses-and-mustache-and-brown-hair

  • ag_yaronag_yaron

    Team Member

    We're glad to hear you love the new features :)

    And yes, descriptive names are hard :lol:

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file