Not overwriting existing environment variables

REBELinBLUE
REBELinBLUE
Community Member
edited February 2023 in CLI

Can someone tell me what I am doing wrong here

According to https://developer.1password.com/docs/cli/reference/commands/run

Duplicate environment variables​
If the same environment variable name exists in both the shell and the .env file, but are referencing different secrets, the variable set in the .env file will be used.

I have GITHUB_TOKEN defined in my shell

❯ printenv GITHUB_TOKEN
ghp_Cq...

I want to use a specific token from 1password so using op read I do the following

❯ op read --account=[account id] op://Personal/Github/terraform
ghp_Sw...

but when I create an .env file with the following content, op run is using the original value (but asking for permission to access 1password)

GITHUB_TOKEN=op://Personal/Github/terraform

❯ op run --account=[account id] --env-file="./.env" -- printenv GITHUB_TOKEN
ghp_Cq...

Comments

  • Nhat_Nguyen
    Nhat_Nguyen

    Hello @REBELinBLUE,

    Thank you for reaching out to us. I can reproduce the issue on my end, and 1Password does use the variable in shell instead of .env file. I will report it to my team for further investigation. In the meantime, we can try some of these options to get the correct env we want.

    1. You can edit the name of GITHUB_TOKEN in .env file to something different and run
      op run --account=[account id] --env-file="./.env" -- printenv NEW-VAR-NAME
    2. You can unset GITHUB_TOKEN, and add both GITHUB_TOKEN to .env file with different names, or you can create a new file with .env extension. Let us call it token2 as an example and put the old value there so when you need to run it, you can use op run --account=[account id] --env-file="./token2.env" -- printenv GITHUB_TOKEN

    Best regards,
    Nhat Nguyen.

  • REBELinBLUE
    REBELinBLUE
    Community Member

    thanks, I've unset the shell one for now as it's a very limited scope token and only used rarely by a few of my dev tools

  • quietbook0298
    quietbook0298
    Community Member

    I can reproduce this on v2.19.0

    Might it be worthwhile to note this as a known issue in the docs (website or op run --help) since they both explicitly state that .env takes precedence?

This discussion has been closed.