hey @nyoungb2,

First of all, thank you for your patience in getting a reply. I can imagine how it's like to spend time trying to solve your case and then wait for additional help.

I will try to respond to the things that I've identified in this thread so far to give some direction moving forward.

If I run 1password: Preview with secrets, then my AWS secrets are correctly substituted in the preview, but those secrets are not substituted when I re-build my container.

The preview just shows what the file would look like with the injected secrets in them. If you want to use the file with the injected secrets when rebuilding your container, then save the preview file and point to it when rebuilding.

Another option would be to use op inject in your rebuild script. Here's an example:
```
op inject -i containerEnv.json -o tmpEnv.json

Run commands for rebiulding container and reference tmpEnv.json to use the actual secrets from 1Password

...

Delete the resolved file since it's no longer needed

rm tmpEnv.json
```

However, I then have to manually sign in during the setup, which requires 4 items of information to type in, including a long secret key. After the setup is complete, I then have to sign in again via eval $(op signin) if I want to use op within my devcontainer.

So there's no way to provide my sign-in address and email op signin? I always have to manually typo both when running eval $(op signin)?

I also have to get a "New 1Password sign-in from XXX" notification email every time? This gets really tedious when re-building devcontainers.

This sounds like a use case in which Service Accounts would be more helpful for you. All you'd need to provide to your devcontainer is the OP_SERVICE_ACCOUNT_TOKEN environment variable with your service account token and then you'd be able to use the CLI in the devcontainer to create secrets in the desired vault.
Check it out and let us know if it simplifies your use case.

In regards to the "cannot hover over the op:// links" issue, I did some testing, and the hover only works for log projects, and not remote ssh connections.

The 1Password VS Code extension relies on biometrics being available on the machine the extension is called from. Therefore, I feel like it is quite unlikely to work with secrets from a remote connection. This sounds like a nice enhancement that it's worth exploring. Thank you for this feedback!

I hope that this answers most of your questions and concerns.

Feel free to reach out if you have any other issues or follow-up questions.