Forum Discussion

suitewill's avatar
suitewill
New Contributor
11 months ago

Injecting secrets with op command does not work with Work Organization account

I am experiencing the same issue as discussed on this closed thread:

https://1password.community/discussion/137489/how-to-inject-secrets-int-oenvironment-variables-when-using-multiple-accounts

I am using op version 2.30.0

I get the account USER ID from the op accounts list and whether I use the --account flag or the OP_ACCOUNT env variable I see the same result:

```
❯ op accounts list
URL                                     EMAIL                                       USER ID
workorg.1password.com    mailto:workemail@example.com         YFHU••••••••••••••YJA
my.1password.com             mailto:personalemail@gmail.com        6LZDD••••••••••••KWA

❯ export OP_ACCOUNT=YFHU•••••••••••••••••YJA
❯ op run --env-file=.env --no-masking -- printenv API_TOKEN
[ERROR] 2024/09/26 14:58:35 "Personal" isn't a vault in this account. Specify the vault with its ID or name.
```

The Work account does not have a Personal vault, it has an Employee vault instead. As well the vault is specified in my op:// URI so I am not sure why it even attempts to access a "Personal" vault.
Example op URI: op://Customers/TestScript/API_TOKEN where Customers is the Vault name, TestScript is the Item name and API_TOKEN is the field name.

If I specify a URI for my personal 1password account everything works as expected.

Any help would be appreciated!

1Password Version: 8.10.44 (81044034)
Extension Version: Not Provided
OS Version: macOS 14.6.1
Browser: Not Provided

CLI

7 Replies

    • 1P_Phil's avatar
      1P_Phil
      Icon for Moderator rankModerator
      7 days ago

      Hi michaelyork​, suitewill​ - (et. all),

      I think at this point it is up to us to consolidate the "why" into a case for why it is important to fix this.  I have a few assumptions (below), but I would like to see if there are additional reasons why.

      Developer Workflow

      • adds friction: having to pass --account/OP_ACCOUNT breaks portable scripts and team docs when teammates have different default accounts. Slows down onboarding/ramp of developers.
      • URI assumptions: The op://vaultID/item/field ref looks globally unique; there’s no place to add account, so they expect the tool to infer it.

       

      Precedent: existing tools infer the full scope from the resource identifier; users expect the same here.

      • AWS CLI (s3://my-bucket/)
      • HTTP ...


      Least‑surprise      : if a vault name clearly matches only one signed‑in account, resolving it without extra flags feels natural.

      (Tangentially) UI Cohesion

      • Mental model: “I can see the Work vault in 1Password → a reference to that vault should just work.”
      • Desktop UI shows all signed‑in accounts unified, so users assume the CLI will behave similarly.

       

      • michaelyork's avatar
        michaelyork
        Frequent Contributor
        7 days ago

        Hey 1P_Phil​ – not sure I understand. It just...doesn't work right now? What's the case to be made?

        If you have multiple accounts connected to your CLI (whether by desktop app integration, or by signing in directly via CLI), there is no way to use `op run` with the non-default account (and there is no way to set the default account).

  • 1P_Phil's avatar
    1P_Phil
    Icon for Moderator rankModerator
    3 months ago

    Hi all ( suitewill​  & michaelyork​ ),

    Thanks for dropping in. 

    One thing that will help the "op" command to sort out "which account is used" is specifying the VaultID.  You can use the "op vault list" command to figure out the ID:

    ➜ op vault list
ID                            NAME
lfbku2r3s6asvuf5o73{REDACTED}    temp demo vault
fi52webk2lwhpvusk2{REDACTED}    throw away vault

    then you need to update the URI to use the Vault ID instead of the name of the Vault.

    op://{VaultID}/TestScript/API_TOKEN

    Let me know if this helps resolve your problem.

    All the best,

    Phil

    • michaelyork's avatar
      michaelyork
      Frequent Contributor
      3 months ago

      Thanks for the reply, 1P_Phil​ . Unfortunately that doesn't resolve the issue (and I think that's been pointed out by other folks in other threads).

      Here's my example:

      op run --env-file="./.env.optest" -- printenv
[ERROR] 2025/06/27 10:44:13 "Personal" isn't a vault in this account. Specify the vault with its ID or name.

      And this is the full content of the env file:

      APPLE_WEATHERKIT_TEAM_ID="op://{vault_id}/Apple/{item_id}"

      Have also tested this by passing in the `--account` flag. Interestingly, 1Password does prompt to unlock the right account when you do this, but then proceeds to return the same error, trying to look up a "Personal" vault.

      • michaelyork's avatar
        michaelyork
        Frequent Contributor
        3 months ago

        For what it's worth, 1Password Support responded with this:

        Thank you for clarifying the issue you are experiencing, I can confirm that a feature request to allow for multiple accounts to be used from the 1Password desktop app when integrated with 1Password CLI has been raised.

        As such, I will attach your report to this feature request to raise awareness within our team for the growing expectation to be able to use multiple accounts within 1Password CLI.

        Unfortunately at this time there is not a workaround for this limitation; it is only possible to sign in to a single 1Password account using command.

        I apologise that this is not the answer you were looking for on this occasion but if you have any questions or if I can provide further assistance do let me know.

        But that doesn't make much sense to me. Clearly the CLI supports multiple accounts (see `op account list`).

        All of the posts I see on the forum seem to be about `op run` specifically not working properly in these cases.

  • michaelyork's avatar
    michaelyork
    Frequent Contributor
    3 months ago

    Experiencing the exact same issue and it's driving us nuts. Looks like it's been a problem for years based on posts on the forum. Would really appreciate a fix.