> For the complete documentation index, see [llms.txt](https://docs.gotempest.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gotempest.app/accounts-vaults-and-privacy/where-tempest-stores-credentials.md).

# Where Tempest Stores Your Credentials

Current account and vault storage: encrypted SQLite documents, sealed per-account secrets, OS-protected host master keys and fallback behavior.

Current Tempest stores account state through the shared native vault host. The encrypted vault database, the account's sealed secrets and the **local host master key** serve different purposes. The host master key is not your Master Password and is not the synced vault key.

## What is stored

| Item                                                                         | Storage and protection                                                                                          |
| ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| Hosts, SSH keys, passwords and Drive document bodies                         | Encrypted document payloads in the local vault's SQLite store; encrypted before sync.                           |
| OAuth tokens, cached vault keys, account preferences and device key material | Per-account `secrets.sealed` files, encrypted with a key derived from the local host master key and account ID. |
| Account registry                                                             | `accounts.sealed`, encrypted under the local host master key.                                                   |
| Host master key                                                              | OS credential store where available; desktop/headless fallback is a permission-restricted `master.key` file.    |
| Document IDs, sync bookkeeping and document timestamps                       | Metadata is not all encrypted; do not assume the entire SQLite file is an opaque encrypted container.           |

```mermaid
flowchart TD
    O[OS credential store] --> M[Local host master key]
    F[Restricted master.key fallback] -. when no usable store .-> M
    M --> R[Open sealed account registry]
    M --> A[Derive per-account sealing key]
    A --> S[Open account secrets.sealed]
    S --> K[Cached vault key]
    K --> D[Decrypt document payloads in SQLite]
```

On desktop, CLI and MCP, the default release shared root is **`~/.tempest/vault`** (debug builds use `~/.tempest/vault-dev`; deployments can override the root). It contains `accounts.sealed` and per-account directories under `accounts/`. Each account has its own secrets and vault files. Desktop, CLI and MCP on the same machine share this root, including refreshed tokens and account selection. Old `~/.tempest/auth.json` sign-in caches may be migrated; they are not the current multi-account storage model.

## Platform protection

### macOS, Windows and Linux native hosts

The native host uses the OS credential store for the master key: macOS Keychain, Windows credential storage, or a supported Linux keyring service. The current desktop/CLI keyring entry uses service **`tempest`**, account **`vault-master-key`**.

Protection depends on the store and OS configuration. Do not assume that every read requires Touch ID or another user prompt, or that all platform credential stores are hardware-backed.

If no usable keyring service is available, such as on headless Linux or in a container, the host persists the master key as **`master.key`** next to the account registry. On Unix it uses file mode **0600**, and restricts the root directory to **0700**. This is a persistent fallback, not an in-memory-only store.

A copy of both the fallback key and the sealed files can expose cached secrets. Protect the directory, the OS user and backups, and use disk encryption. If the OS explicitly denies access to an existing keyring key, Tempest reports the failure rather than silently creating a replacement that cannot open the accounts.

### iOS and Android

The native vault host runs inside the app's sandbox. iOS keeps its host master key in Keychain. Android stores a random host master key encrypted under an AES key in Android Keystore. Hardware-backed protection depends on the device and platform.

An uninstall is not a reliable universal way to erase every credential: iOS Keychain entries can survive uninstall, and backup/restore behavior varies. Use Tempest's account removal/sign-out controls before disposing of a device.

### Web Mode

Current Web Mode uses the **standalone backend's native vault host**, scoped to browser sessions. The account's vault files and host master key live on the backend machine, not solely in browser session storage. The backend is a trusted credential-processing endpoint.

A browser session can reach only its authorized accounts; it does not automatically inherit the server machine's CLI accounts. That isolation does not hide decrypted data from a compromised backend or its administrator. Secure the backend host, HTTPS deployment, session access and its persistent storage.

## Account sign-out and removal

Use the account controls rather than deleting individual keyring entries:

* **Sign out:** clears sign-in tokens and shared-vault state as applicable, but retains personal data as a local vault, normally re-sealed under a device-local key. The account stays listed and the next sign-in can adopt that local data. It is not a data wipe.
* **Remove from this device:** removes the account and its local data from the device registry. Data already synced stays on its server.
* **Switch account:** changes the current account; it does not merge accounts or copy their secrets.

Desktop changes are visible to CLI/MCP sharing the same root. Sync pending changes before signing out or removing an account. Neither operation removes plaintext that you already copied to files, clipboards, logs or other applications.

Do not delete the host master key on its own to “reset” one account: it seals the registry and secrets for **all** accounts in that root. If the key is missing while the sealed registry exists, the native host refuses to silently replace it. Restore the appropriate key/storage together or use a deliberate recovery procedure.

## What local encryption can protect

An attacker who only copies encrypted vault and account files, without access to the OS-protected host master key, has not automatically obtained the secrets. An attacker who can read both a fallback key and the files, access an unlocked process's memory, or read the credential store may obtain them. See the [E2EE threat scenarios](/accounts-vaults-and-privacy/end-to-end-encryption.md#protection-on-the-local-machine).

## See also

* [Accounts & Multiple Accounts](/accounts-vaults-and-privacy/accounts-and-vaults.md)
* [Passwords & Recovery](/accounts-vaults-and-privacy/resetting-password.md)
* [How Tempest Protects Your Privacy](/accounts-vaults-and-privacy/how-tempest-protect-your-privacy.md)