How to get your passwords out if the app stops working

Every password manager has an export button, and it lives inside the app. If the app will not launch after an OS update, or the company behind it stops answering, the export goes with it.

What a real exit path requires

Check your current manager against these four:

1. The format is documented. If nobody outside the company knows how the vault file is laid out, then the file is only readable by software the company chooses to keep publishing.
2. Recovery does not need the main application. A recovery path that runs inside the app assumes the app runs. That is the assumption most likely to be false when you need it.
3. Recovery does not need the network. If a license check, an account login, or a sync service has to answer before you can read your own data, then a company that has stopped paying its hosting bill controls your access.
4. You have tested it. Until you have run the recovery once, you do not know whether it works.

Plenty of managers pass some of these. A cloud manager with a documented export format and a saved export file is in reasonable shape. A manager with a proprietary format, an account requirement and no offline path fails all four: you can read your data only while that company keeps its servers running. What the major managers' exports hold, field by field, is on the export formats page.

Buddy's recovery tool

We publish a separate command-line program called buddy-rescue. It reads a vault, checks your master password locally, and writes out a documented export.

We kept it out of the desktop app so that it carries none of the parts most likely to stop working: it has no licensing, update, browser, analytics or networking code. It is built on the same public crypto core as the app, so the two cannot drift apart. It opens the database read-only, runs no migrations, and writes nothing beside the source file.

Start with inspect. It needs no password and decrypts nothing, and it reports whether the database is intact, which vaults are inside it, and what parameters they use:

$ buddy-rescue inspect buddy.sqlite
Format: buddy-vault-v1
SQLite integrity: ok
Schema migration: 1
Vaults: 1

Personal
  Vault version: 1
  Entries: 214 live, 0 trashed
  Attachments: 12 records, 12 present, 0 missing
  KDF: argon2id · 65536 KiB · t=3 · p=4 · version 19
  Status: compatible

Look at the attachments line. Attachment contents live in a directory next to the database, so a backup that copied only the .sqlite file reports them missing here. Better to find that out now than during a recovery.

Add --json if you would rather have the report in a machine-readable form.

Then export:

$ buddy-rescue export buddy.sqlite --format json --output ./out
Master password:
Recovered 214 entries and 12 attachments to ./out

If the database holds more than one vault, inspect it first and pass the vault you want with --vault <id>. The master password is read from a hidden prompt and is never accepted as a command-line argument, because arguments end up in shell history and process listings. For scripted use there is --password-stdin.

An export is a directory containing a manifest, the entries file, and any attachments:

out/
├── manifest.json
├── entries.json              # or entries.csv
└── attachments/
    └── <blob_id>/
        └── <original_filename>

JSON keeps everything: entry and group IDs, every field shape and role, password history, usage timestamps, trash state, icons and attachment references. CSV uses the same eleven columns as the desktop app's exporter and drops whatever those columns cannot hold, which makes it the one to hand to another password manager.

We wrote the tool to recover what it can rather than stop at the first bad record. Each entry and attachment is authenticated on its own, so one damaged record does not cost the other two hundred. The exit status says how it went:

Status	Meaning
0	Inspection passed, or every requested record exported
1	The command could not run, credentials were rejected, or nothing was written
2	Inspection found damage, or the export finished with record issues

A 2 means you got an export and something in it needs a look. What was skipped, and why, is listed in manifest.json.

Handle the output carefully

An export is your entire vault in cleartext.

• Write it somewhere local, not to a synced folder or a network share.
• On Unix, exports are created with owner-only permissions. That keeps out other user accounts, not malware running as you.
• Delete it when you are done, and remember that a normal delete on an SSD does not reliably destroy the data. An encrypted disk is what makes that deletion meaningful.
• If you exported to move managers, delete it as soon as the import is done.

Test it on a copy

It takes about ten minutes:

1. Copy your vault and its attachments directory to a scratch folder.
2. Run inspect on the copy and confirm it reports the vaults and attachment counts you expect.
3. Run export on the copy.
4. Open the export and check a handful of entries you would hate to lose, including one with an attachment and one with a TOTP secret.
5. Delete the scratch folder.

If inspect reports something you did not expect, send us the output. It lists vault names and counts, never entry contents.

The vault format is documented in full, so a recovery reader does not have to be ours. The format is summarized in the security model, and the repositories are on the open-source page.