Share your Claude Code and 1Password tips!

1Password Environments seem like a good option except they suffer from a few shortcomings currently.

In my case, I have a (normal, not virtual mounted) .env file that only contains secret references and I use `op run —env-file=.env — <command>` heavily, but when Claude Code is working on my behalf I am bombarded with re-authentication prompts as it likes to repeatedly run my test suite to validate its own work.

I had hoped that environments might help here, but it seems like if I mount the environment as a virtual .env file I still need something (dotenv) or similar to load that file into env vars for the command to access them. I believe this solves the auth prompt issue (as long as the desktop app is unlocked), but has other issues like only one process is allowed to read the virtual .env file at a time?

Alternatively I could skip the .env file altogether with `op run —environment <id> — <command>`, but that doesn’t reduce the number of auth prompts. It would be great if the `—environment` argument could require fewer auth prompts (similar to the virtual .env mount approach).

Then there is the complaint many others had that environments don’t support secret references, so you need to duplicate a secret already in the vault into the environment.

It seems like we’re so close to the nirvana of not having secrets stored on disk while still allowing agents to do their work (with access to environment secrets) without a human having to babysit them just for secret access.

Unless I’m mistaken on any of the above?