34 lines
1.1 KiB
Markdown
34 lines
1.1 KiB
Markdown
# Storage
|
|
|
|
Sherlock stores credentials only in the OS keyring through `internal/keyring`.
|
|
There are no plaintext token files and no sherlock daemon state.
|
|
|
|
## Wallet
|
|
|
|
Each service has one wallet entry under keyring service `sherlock` and account
|
|
`service:<name>`. A `services-index` side entry makes `sherlock status` portable
|
|
across keyring backends.
|
|
|
|
Stored data includes the service tokens, expiry times, OAuth
|
|
issuer/client/scopes needed for refresh, and user identity metadata.
|
|
|
|
## Pre-flight
|
|
|
|
`keyring.Open()` probes the OS keyring before returning a store. Missing or
|
|
locked keyrings return `*keyring.UnavailableError` with a remediation hint;
|
|
CLI/MCP callers exit with keyring failure rather than silently falling back.
|
|
|
|
## Runtime files
|
|
|
|
Runtime files live under `$XDG_RUNTIME_DIR/sherlock/` or the sibling runtime
|
|
directory:
|
|
|
|
- `<agent>.mcp.json`: generated MCP config, mode 0600.
|
|
- `sherlock.refresh.lock`: cross-process token refresh lock.
|
|
- `sherlock.login.lock`: cross-process first-login lock.
|
|
|
|
## Platform note
|
|
|
|
Linux needs a Secret Service provider available in the user session. macOS uses
|
|
Keychain; Windows uses Credential Manager.
|