[60] Where is the local cache stored? Cleanup local config and cache on `op signout`?

Hey @smanojkarthick , I think I can be of help here.

When running on remote machines, I would like to clean up any local config or cache stored in the system after scripts that make use of 1password secrets are complete. Knowing where the cache is stored would help clean up any confidential remnants.

We do not write any cached contents into the disk.

Instead, we run a daemon process called op daemon in Linux and MacOS versions of the CLI.

The daemon stores encrypted objects (vaults and their items) in-memory, and when op requests for a cached item, it is then passed along to the CLI via a socket.

Note that the daemon process itself cannot read the contents of your vault items because it does not have the decryption key.

If you still wish to terminate the daemon process, I would recommend running ps aux | grep "op daemon" to find the PID and terminating it, but note that another process would start on the next time the CLI authenticates.

I also expected that op signout would clean out any secrets left in the system. But, looks like the account secret key is still stored on the system after explicit signout

Correct! The op signout command forgets the session key that's required for the commands to make API calls to the server. It will not remove any account related configurations that we save to the disk, which the secret key is a part of.

However, if you do wish to completely forget the details of an account, you can try the op account forget command (previously op forget in v1) which will remove the account info from the configurations files.

Please let us know if you have any further questions!

This is great, Thank you!

Happy to provide the info!

I just wanted to touch back and mention that I forgot about a command that we have built into the CLI!

Check out the op daemon --help command on more info on how to manage the daemon process. Looks like it is configured to terminate after being inactive for 24 hours, but this value can be modified with the --timeout flag.

Hope this helps!

Oh, I wasn’t aware of that - thanks for the info!

By the way, we are aware of a recent bug that results in the cache daemon process not starting, and the --cache flag being ignored when using biometric auth to sign in. We are working on fixing that!