I'm not sure if it's good to unconditionally always run op (with the need to authenticate)

We could solve for the authentication part by having op run only prompt for authentication when secrets are configured. If no secret references are in the environment and environment files, op run should just be able to start the command without authentication imo.

@"Justin.Yoon_1P"

Ideally, I dont' want to actively run any commands manually but want my secrets to be resolved as soon as I cd into a directory. I understand thats very wishful thinking (and very lazy).

So in the case of direnv, I don't think the op shell command will work without further tweaks in the .envrc file. Whenever you cd into a directory with an .envrc file, direnv executes the .envrc file. While you can export variables, you can also put any arbitrary command there. If I put op shell in my .envrc, the shell will load again and because my .zshrc has the direnv hooks installed, it would see the .envrc, execute it, spawn a new shell, ... and so on.

I've run a quick test:

.envrc

$SHELL


result:

Thanks for your feedback @rknshia ,

I am wondering what your opinions are on an upcoming command for starting a new shell via op shell --env-file that would load the env file secrets references into a new shell, as opposed to creating the shell manually.

I am also interested in what kind of infinite loop cases in new shells that cause you concern, as I'd like to bring them up to the individual developing the op shell command as well.

@"Justin.Yoon_1P" I didn't like starting another shell from my .envrc file (as that might also cause some infinite loops I guess as the next time I switch to that directory it would try to reload the .envrc), so here's my quick (and ugly) fix for now. I am losing out on the masking by op run, but I don't have to do anything manually when I go to the directory anymore.

Maybe it helps someone else:

```sh
eval $(cat <<EOF |
export MY_USERNAME="op://prod/account/username"
export MY_PASSWORD="op://prod/account/password"
EOF
op inject)

```

Hi @"Justin.Yoon_1P",

I don’t think it will work necessarily as the envrc file does not follow the syntax that the op run command expects for env files, but I haven’t tried it yet - will give it a go later though and report back :)

Hey @rknshia ,

Would running op run --env-file .envrc -- $SHELL to load an instance of a shell with all the op:// references resolved be helpful for your use case?

We are also currently implementing this as a distinct command op shell, so keep an eye out for that as well!

Hi,

You might be interested in https://1password.community/discussion/126437/16-17-20-37-38-support-for-both-versions-in-scripts about direnv (although mostly for supporting both v1 and v2). There is also a link to my PoC direnv extension.

I think the hard part is to come up with a good user interface.

It could be possible to trigger op run for all variables at the end of .envrc evaluation, but I'm not sure if it's good to unconditionally always run op (with the need to authenticate). And also someone might not be happy to feed all their variables to 1Password CLI.

How about adding e.g. use op direnv stdlib command (with an extension), which would trigger the evaluation at the end? Although that might require a bit of hacking or changes in direnv, as there are no support for this kind of post evaluation hooks as far as I know. But we could test if we can hijack the EXIT trap for the first test.