Forum Discussion

integralist's avatar
integralist
New Contributor
2 months ago

Why does the 1P CLI not access the local 1P store?

👋

I have a shell script with lots of "secret references"...

export EXAMPLE1_API_KEY=$(op read "op://<VAULT_NAME>/<ENTRY_NAME>/<SECTION_NAME>/<FIELD_NAME>")
export EXAMPLE2_API_KEY=$(op read "op://<VAULT_NAME>/<ENTRY_NAME>/<SECTION_NAME>/<FIELD_NAME>")
export EXAMPLE3_API_KEY=$(op read "op://<VAULT_NAME>/<ENTRY_NAME>/<SECTION_NAME>/<FIELD_NAME>")

Every time I load my terminal shell it takes an age for each secret to load.

I was then told by someone that the 1P CLI doesn't actually communicate with the local 1Password app, but instead it goes remotely to fetch the data (which in the case of my friend, they couldn't load their shell once when 1Password had remote access issues, hence they discovered what was happening).

But for me, I'm wondering, is this why it can be so slow to load a terminal shell when you have lots of secret references? each secret, is a new CLI invocation, and then that has to be individually making remote calls with authorization etc etc.

Is there any way to speed this up?

Is there a reason for not consulting the local 1Password app data? Or does that 1P app not actually store any data and any time you're logging into that you're actually just doing a bunch of remote calls to pull data down?

Thanks!

CLI

4 Replies

  • Scott_1P's avatar
    Scott_1P
    Icon for 1Password Team rank1Password Team
    29 days ago

    Hi Integralist!

    Really cool to see someone leaning hard on secret references! 

    As you note, the CLI is on the slower side. Running `op item get $someItem` gives you a sense of how long that takes. In my experience most item-level operations can take about one second. 

    Every time I load my terminal shell it takes an age for each secret to load.

    Based on this, it sounds like you're using these secret references in a script that is loaded by your shell configuration, hence why it's slowing down any time you open a new shell? 

    If my inference is correct, I might recommend not loading these as part of your shell configuration (partly because if you are unable to unlock 1Password then you can't instantiate a terminal session....) 

    Without knowing more about your use-case or whether this is part of your shell config or a script you run, here are a few things to explore that _may_ help depending on your use-case:

    • Our SDKs fair bit faster than the CLI, and there are some methods (e.g., client.secret.resolve_all() or .resolve()) that you can use to resolve a secret reference to it's value, optionally in bulk. If you're able to write the script in Go, Python, or JS, this might be faster.
    • Our Shell Plugins may be helpful if the secrets you're resolving are credentials for CLI tools you use. Using one of these plugins means you can avoid loading all those secrets when launching your shell, and obtain only the secret you actually need in the moment you need it. 

    If none of the above are really hitting the mark, maybe you can share more about the specifics of your use case? 

    • integralist's avatar
      integralist
      New Contributor
      28 days ago

      Thanks. It sounds like the shell plugin might help. I'll look into it more later and report back. Sounds like I can just create a custom shell "plugin" without having to necessarily contribute it back upstream to the relevant GitHub repo. 

      • Scott_1P's avatar
        Scott_1P
        Icon for 1Password Team rank1Password Team
        28 days ago

        Sounds like I can just create a custom shell "plugin" without having to necessarily contribute it back upstream to the relevant GitHub repo.

        Oh, now that's an interesting idea! Hopefully that makes the experience a bit smoother for you! Report back with how things go! 

  • phildmno's avatar
    phildmno
    Occasional Contributor
    29 days ago

    As far as we've found building integrations with CLI/SDK/App at DMNO, the CLI will only use the local app for auth (like biometrics) and all the data fetching still happens remotely. We've had to work around this as well and would love if the CLI/SDKs could fetch from a local cache as well.