Four things the first pass threw away, all of them recorded in the mapping notes
from the 2026-09-02 hand conversion and all of them silent.
Item ids were regenerated. Bitwarden ids are already UUIDs, so keeping them is
what makes a re-import idempotent: run the same export twice and the second run
reports its items as already present under "skip", rather than duplicating the
entire vault. createItem deliberately refuses a caller-supplied id and always
mints a fresh one, so the id is adopted after construction, and only when it
really is a UUID.
Timestamps were restamped to "now". creationDate and revisionDate are the only
record of when a password was last rotated, and overwriting them destroys that
permanently. The oldest item in a real export dates to 2018; every one of them
would have been dated today.
Password history was dropped entirely. It is carried now, newest first, mapping
lastUsedDate to changedAt and capped at MAX_HISTORY_ENTRIES. 189 items in a real
export have history, so this was not a rare case.
URI match rules were hardcoded to "domain". Bitwarden stores them as a number --
0 domain, 1 host, 2 startsWith, 3 exact, 4 regex, 5 never, with null meaning
domain -- and flattening them quietly widens a login pinned to an exact URL,
which is a security change rather than a cosmetic one.
Verified on the same 4,395-item export: all 4,395 ids carried across, stable
across two runs, 189 items with history recovered, and the oldest createdAt still
2018-02-22. That export happens to use domain matching throughout, so the match
mapping is covered by tests rather than by it.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Importing a Bitwarden export failed with "Not an OpenCreds database" and had to
be converted by hand first. The import command decided what a file was by
`text.trimStart().startsWith("{")`, and treated every JSON as an OpenCreds
database. A Bitwarden export starts with a brace too, so it went to parseDatabase
and was rejected there.
JSON is the format Bitwarden's own UI hands you by default, and the only one of
its formats that keeps folders, custom fields, multiple URIs per login and full
card/identity detail. Its CSV drops all of that, so "export as CSV instead" is a
lossy workaround rather than an answer.
The shape is now sniffed before deciding which reader owns the file: an `items`
array plus either a `folders` array or the `encrypted` flag. An OpenCreds
database has neither at its top level, so the two never collide, and a cheap
substring test means a large database is not parsed twice to find that out.
Everything the format carries is mapped: all four item types, Bitwarden's own
folder ids (so two folders sharing a name stay distinct), custom fields with
their hidden flag, every URI rather than only the first, TOTP secrets, and
favourites. An untitled login is still named after its host. A folderId naming no
folder is dropped rather than inventing a folder, and only folders something
actually landed in come back, so importing one item out of a big export does not
create sixteen empty folders beside it.
An encrypted export is refused outright instead of half-read. Its items are
opaque strings, so a best-effort parse would store ciphertext as if it were a
password and leave a vault full of junk that never decrypts.
Verified against a real 4,395-item export: 4,387 logins, 3 cards, 4 identities,
1 note, 16 folders, zero skipped, parsed in 56ms. Every count matches the source
file, and the command that used to fail now reports "(Bitwarden JSON)".
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
