How to inject secrets int oenvironment variables when using multiple accounts?

Community Member

I use multiple accounts and look into using secret references as my environment variables.

How to I achieve this with multiple accounts:

This example above works when using a single account, not sure how to use this approach with multiple accounts.

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser:_ Not Provided


  • Hi @dzhi:

    Great question! It's only possible for 1Password CLI to be signed into a single 1Password account at a time.

    For example, if I run op signin, I can pick between my work account, and my personal account, and any references I use would be are op://<vault name>//<item name>//<field>.

    Would you mind sharing a bit more about your use case where you need secrets from two accounts?


  • hotfix
    Community Member

    I would love for the possibility to use secrets from multiple accounts in my env file. For example:


    Unfortunately, I then get:
    Error executing CLI command: "Personal" isn't a vault in this account. Specify the vault with its ID or name.

    Error executing CLI command: "Private" isn't a vault in this account. Specify the vault with its ID or name.

    Depending on the account I am logged in with.

    Is there any chance this will be possible in a future release?

  • danielharvey
    Community Member

    @Jack.P_1P Here is what I find.

    This works:

    op read --account account-name "op://Private/xxx/yyy/databasePassword"

    This works:

    MYSQL_PWD=$(op read --account account-name "op://Private/xxx/yyy/databasePassword") mysql -h -u admin  -P 3307 dbname

    This fails:

    MYSQL_PWD="op://Private/xxx/yyy/databasePassword" op run --account account-name -- mysql -h -u admin -p -P 3307 dbname

    with the error
    [ERROR] 2023/04/11 17:59:42 could not resolve item UUID for item xxx

    ie op run does not accept the --account parameter

  • Hello @danielharvey,

    We were unable to replicate your issue, the --account parameter should work, is it possible that your item path is wrong, or something else?

    Let me know!

  • poordecisions
    Community Member
    edited December 2023

    Same issue. The op read hack isn't as secure since it ends up writing the keys to the environment rather than resolving at runtime. And account params don't work with op run... I really need to set env variables whose values come from 2 accounts using the op run url. Please introduce a variance of these URLs that tell one password which account to access as part of the lookup during op run.

    Using the op run hack, I get prompted every time I open a new terminal window as it initializes and tries to resolve my environment. This makes the feature totally untenable in a real world use case