Populate environment variable for active shell session

My pleasure. Let us know if we can help with anything else. :)

Best,
Horia

Sounds great, @"Horia.Culea_1P". Thanks for the insight

Hey @dnsstaiger, thank you for reaching out!
Not yet! This project is still with our Product team, considering the use-cases and potential areas where such a feature would benefit the workflows of our users.
We'll keep this thread updated, when we have news about this.

Best,
Horia

@"Horia.Culea_1P" I have been keeping an eye on the latest op cli releases since you mentioned a feature coming up to simplify this type of integration:

We are currently working on some native way to achieve this with the CLI, so stay tuned for the next releases!

Has this feature landed yet? If so, can you point me into the right direction? Really looking forward to a slick integration with direnv (or an alternative approach which does not require direnv to safely set env vars for a directory/session).

Thanks!

See the entire discussion here: https://1password.community/discussion/126437/16-17-20-37-38-support-for-both-versions-in-scripts

It might also be worth checking out this third-party integration developed by one of our customers: https://github.com/tmatilai/direnv-1password

No worries, let us know if we can help with anything else!

Hi @"Horia.Culea_1P". Thanks a lot for the insight. Besides the security aspect, I found that my approach is quite slow when loading 10 to 20 secrets that way. This is most likely the case because of running op for each secret separately, so your suggestion with using a priviledged shell session might make things more performant.

I am happy to try the improved process once it becomes available.

Hey @dnsstaiger, thank you for reaching out to us!

We are currently working on some native way to achieve this with the CLI, so stay tuned for the next releases!

In the meantime, there is a workaround for this: you can move your direnv environment variables to a .env file, replace their values with secret references, and start a privileged session, with access to these secrets, using op run --env-file .env -- $SHELL. Please do mind that you'll need to explicitly terminate this session (exit) at the end of it, in order to de-populate the environment.

Another possibility is using direnv in conjunction with op run: adding envvars with secret references in your .envrc, and starting a privileged session from within the directory. In this case there would be no need for a .env file, since the envvars in question are in your session environment: op run -- $SHELL. Once again, please do proceed with caution and exit the privileged shell once access to the secrets is no longer needed.

Please let us know if this helps. This process is a bit cumbersome at the moment, so we hope you'll try the native CLI approach, once it comes out.
We're looking forward to hearing from you!

Best,
Horia

I did find a way to use direnv to set the variables: https://1password.community/discussion/comment/634363#Comment_634363. This is probably good enough for my needs and since the variables are unloaded the moment I exit the directory, it is somewhat secure.