[aakashns]

Settings has a new last row, Change password. Enter or a click opens a dialog with three boxed password fields: current password, new password, confirm new password.

• Tab (or ↑/↓) moves between the fields. Enter goes on to the next empty field, then changes the password. Esc or Cancel closes the dialog. The fields and both buttons can be clicked.
• A wrong current password, a confirmation that doesn't match, or a new password under 8 characters (the same rule as setup) is shown in red in the dialog, and the dialog stays open.
• While the change runs, the dialog shows "Changing the password…". Then Settings shows "Password changed."

What happens to the vault

1. It checks that the current password gives the open vault's key.
2. It makes a new random salt and the new Argon2 key, and backs the vault up next to itself (writui.db.password-<time>.bak).
3. SQLCipher's rekey re-encrypts every page in one transaction and writes the new salt into the file.
4. The vault is then reopened from scratch, exactly as an unlock would: the salt is read from the file and the key comes from the new password. It must pass both integrity checks and hold exactly the same data as before (a SHA-256 over every row of every table). Only after that is the backup deleted.
5. If anything fails after the backup is made, the vault is reopened with the old password. If that doesn't work, it's copied back from the backup and checked the same way. Settings then says why the change failed and that the old password still works. Only if even that fails does writui stop, with an error saying where the backup is.

Touch ID: if it's on, its key file is made again for the new key (that doesn't need a fingerprint). If that fails, Touch ID is turned off and Settings says so.

Checked

• 170 tests pass; clippy and fmt are clean. New tests: a successful change (old password refused, new one works, everything kept, backup gone), a wrong current password (file byte-for-byte unchanged), and three ways for the change to fail after the rekey: a failing check, a damaged vault, and a damaged vault and backup. The first two leave the old password working with nothing lost; the last keeps the backup and names it.
• Against a vault made by the 0.19.0 release binary (two posts, a saved version, author and styling settings, Touch ID on): this build changed its password. Afterwards the file has a new salt and no backup is left. The 0.19.0 binary then refuses the old password and opens the vault with the new one: both posts, the "First draft" version and the settings are all there.
• Touch ID: with it on, changing the password rewrote its key file and kept Touch ID on. Not tested: actually unlocking with a fingerprint after a change, since that needs your finger. Please try it (below).

Try it

gh pr checkout 34 && cargo run

Debug builds use .dev-data/ (password writui-dev), never your real vault. In Settings (s on the list), go to Change password and change writui-dev to anything, then press Ctrl+O and unlock with the new password. Change it back to writui-dev when you're done.

To check Touch ID too: turn it on in Settings, change the password, quit, and start cargo run again. It should ask for your fingerprint and unlock.

Also in this PR: 0.20.0, README (how to change the password), SPEC, DECISIONS and PLAN.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

🚀 Deploying Preview to Cloudflare 🚀

Preview Deployments by commit

Status	Deployment URL	Commit	Updated (UTC)	See this deployment's details
Build: Success ✅ View logs ↗	No Preview URL. Enable ↗	727042d	2026-10-19T08:50:41.070Z	Visit the dashboard ↗