Question

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

Forum|Forum|1 year ago
September 27, 2024
3 replies
398 views

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

M

michaelyork

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.

A

Anonymous

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

M

michaelyork

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.

M

michaelyork

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.

M

michaelyork

@1P_Phil Any chance we can get this resolved?

A

Anonymous

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.

M

michaelyork

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).

Sign up

1Password employees: Sign in with SSO

Login to the community

1Password employees: Sign in with SSO

Scanning file for viruses.

This file cannot be downloaded