Repository navigation
persist auth state when used in a cli command #230
Description
Current Behavior
If you use op it can remain logged in for multiple command invocations, but if you write a CLI tool with the onepassword-sdk-python you have to re-authenticate every time. If your cli tool has a configuration file where you put onepassword reference strings into it, having the CLI tool subshell to op lets the user stay logged in for a few minutes and not have to re-auth every time they run your command, but with onepassword-sdk-python you have to re-auth on every command.
Desired Behavior
Some sort of auth persistence similar to how op works. My use-case is that every employee has a onepassword account and I want to use their individual onepassword accounts so that I can provision secrets in onepassword and use onepasswords user and group permission management structure, but employees should be able to run a cli command that uses these secrets if they have permission for those secrets.
Benefits & Value
If I subshell to op, then users stay logged in and they can run my command repeatedly, but the performance of looking up, say, 8 secrets is not as fast as using the sdk. If I use the sdk, resolving the secrets is faster, but the users have to re-auth every time. I'd like to combine the auth persistence of op with the lookup performance of the sdk.
Additional information
Compare this program:
import asyncio
import sys
from onepassword.client import Client, DesktopAuth
async def main() -> None:
reference = sys.argv[1]
client = await Client.authenticate(
auth=DesktopAuth(account_name="whatever"),
integration_name="op-read",
integration_version="v1.0.0",
)
print(await client.secrets.resolve(reference))
if __name__ == "__main__":
asyncio.run(main())to the behavior of op read. If you do op read op://Private/etc/you-get-it twice in a row, you only have to auth once. If you do python op_read.py op://Private/etc/you-get-it twice in a row, you have to auth both times.
What I don't want to do is give people (ok, let's be honest, me) a reason to say "ok I'm going to speed this up" by exfiltrating the secrets into something like a redis docker container.
Activity
Richyread commentedon Aug 12, 2026
Not an objection to the request, and the underlying need is real: re-authorising on every invocation makes the SDK awkward for short-lived CLI processes, and the pressure to cache secrets somewhere worse is a genuine consequence of that.
The concern is the shape of the fix. Persisting auth across processes would replace one fixed behaviour with another fixed behaviour, and the current one is load-bearing for at least one class of user.
Our case is that we use the SDK as a human-authorisation gate rather than as a secret source. A
pre-pushgit hook callsClient.authenticateand allows the push only if the person at the machine approves the 1Password prompt. No secret is ever read; the authorisation itself is the deliverable. That works today precisely because authorisation is per-process and a hook is a fresh process every time, so every push raises a fresh prompt. If auth persisted across processes, the second and subsequent pushes inside the window would complete silently, and the gate would quietly stop being a gate.So rather than choosing between always-prompt and cached, could the cache be configurable by the implementor at client construction?
none: today's behaviour, every process authorises.That gives the requester what they need without removing what the current behaviour guarantees, and it puts the choice with the integration author, who is the one who knows whether they are fetching a secret or gating an action.
If persistence does land as a default, an explicit opt-out would cover our case, though default-off would be safer for anyone relying on today's behaviour without realising they are.
jordanorelli commentedon Aug 12, 2026
sounds a lot like an AI-authored comment. If you're gonna use AI to author your comments about how you use the onepassword sdk to not read secrets but to get the system security prompt to appear, presumably because you're using --dangerously-skip-permissions and you want to force your agent to stop only on specific things where you insert stop points, you could use your AI to code up a separate sdk that triggers the system security prompt.