Device-encrypted caching for op - fewer round-trips, no unlock prompt storms

I’m one of the creators of varlock. We build free and open source tools for secrets and configuration, including plugins for all the popular providers including 1Password. Since op CLI latency and repeated unlock prompts are two recurring pain points in this forum, I wanted to share something we just shipped specifically for 1Password users - and for ourselves, since we are 1Password users too!

While varlock already adds validation and many other DX improvements on top of 1Password, we've now added a built-in cache that sits in front of op calls, so repeated secret loads don't keep hitting remote servers. There are already a few lightweight op cache wrappers out there, and while they help with speed, they generally give up op's session-scoped biometric unlock, and could leave plaintext secrets available in memory. We wanted the speed without sacrificing security.

As an added bonus, our own “session” logic is a bit more flexible than op’s, and helps reduce spurious unlock prompts in cases where it feels unexpected - like parallel reads in turborepo, and non-TTY uses like claude/codex desktop apps.

How it works

Varlock loads secrets from a declarative .env.schema via its 1Password plugin. It supports both traditional vaults and the newer Environments. The plugin writes values to a secure cache, and subsequent reads will use the cache instead of extra roundtrips to 1Pass servers.

On the first read, you’ll see the 1Password prompt (if using local desktop app auth via the CLI). The next read (which hits the cache) will show the varlock prompt. After that, no more prompts (in that session) until any of - call `varlock lock`, machine locks/sleeps, or inactivity timeout. If you'd rather not use Desktop app auth, you can use a service account token, and varlock will you encrypt and secure that too.

The cache encrypts values at rest, keyed to your device (Secure Enclave + Touch ID on mac, Windows Hello / DPAPI on Windows, TPM2 on Linux). No plaintext secrets left lying around. If no hardware backend is available, it stays in-memory only for that run rather than writing plaintext to disk.

This isn't a replacement for op - it's built on top of the CLI/sdk and 1Password stays the source of truth. We'd genuinely love feedback, especially from anyone who knows op's internals well. Happy to answer anything here.

---
An example .env.schema - caching is enabled by the cacheTtl option

# @defaultSensitive=false @defaultRequired=infer
# @plugin(@varlock/1password-plugin)
# Uses OP_TOKEN in CI/deployed envs, othewise use local app auth
# @initOp(token=$OP_TOKEN, allowAppAuth=true, cacheTtl=1h)
# ---

# 1Password service account token. Set directly in CI/deployed env
# @type=opServiceAccountToken @sensitive
OP_TOKEN=

# @sensitive
XYZ_API_KEY=op("op://acmecorp-ci-secrets/xyz/api-key")
XYZ_ACCOUNT_NAME=acmecorp # non-sensitive config can be hardcoded

# ...