UX proposal: sort vault items by creation date (cross-client, staged rollout)

[TechFath3r]

Select Topic Area

✅ Code Contribution Proposal

Code Contribution Proposal

Hi maintainers — per the contributing guide I'm opening this as a Discussion to get your input on a UX change before writing code. CLA is signed.

The change, in one sentence

Let users sort their vault list by creation date (newest first / oldest first), so they can find a recently-added item by scrolling chronologically when they can't remember its name.

Why this, why now

Users frequently sign up for a service, save it to Bitwarden, and later can't remember the exact name to search for it. Competing managers (1Password, KeePass) solve this with a date-sort. It's the reason I'm considering switching to Bitwarden from 1Password.

Community demand has been consistent and unanswered for nearly 8 years:

• Sort items by date of modification, addition, last use, etc — October 2018, 61+ likes on the OP, 12+ pages of replies, now locked
• Sort Entries by "Recently Added" and "Recently Modified"
• Bitwarden Browser Extension Vault Sorting
• Add sort by for objects in vault
• Sort Vault Items by Revision Date Using the CLI

A third party even published a workaround blog post piping CLI exports through jq, which suggests the demand is real enough that users build their own tools.

Related proposal

Kevin Rossen proposed a similar "Recent Items" feature for iOS in org-level discussion #16874 (Oct 2025, currently labelled pr-proposal-stage2-product-review and awaiting review). This proposal is the counterpart for the clients-repo targets (desktop/web/browser) and doesn't depend on or duplicate Kevin's iOS work — the two together would give users consistent chronological access across every client.

What I'd like your input on

Four UX decisions I'd rather land with you before I write code, rather than discover in PR review:

1. Column vs. sort menu on desktop/web
Desktop and web already use bitSortable column headers for Name and Owner. My instinct is to add a "Created" column (responsive-hidden on narrow viewports, matching the existing Owner column pattern). The alternative is a sort-selector menu/dropdown that doesn't show a date column. Column feels more consistent with existing patterns and gives users an at-a-glance date. Your preference?

2. Creation date vs. revision date as the first option
I'm proposing creation date first because it matches the "find my recent signup" user story directly. Revision date is also useful (sort by recently-modified) and could be a follow-up toggle. Is there a reason to prefer revision date, or to ship both at once?

3. Staged client rollout
I'd like to ship in this order to keep each PR small and reviewable:

Stage	Client	Effort
1	Desktop	Small — follows existing SortFn/bitSortable pattern
2	Web	Small — near-identical to desktop
3	Shared persistence	Add VAULT_SORT_ORDER under VAULT_SETTINGS_DISK so sort choice persists
4	Browser extension	Medium — different paradigm, wants design input
5	Mobile (iOS/Android)	Separate repos, out of scope for clients

Stages 1–2 are almost copy-paste once the pattern's agreed. Stage 4 is where real design discussion is needed — the popup has no column headers and groups by cipher type, so "where does the sort toggle live in a 360px popup" is a UX call I'd want you to make. Is the staged sequencing reasonable, or would you prefer a single coordinated PR across desktop+web?

4. Grouping / timeline view (later follow-up)
A natural next step is section headers that group items by month/year (like a phone photo timeline), so users can skim "January 2025" → "February 2025" → etc. This would be a separate, larger proposal after stages 1–3 land — flagging it now so you know the direction but not asking you to decide on it today.

Technical notes

• Data is already there. CipherView.creationDate: Date is populated on the client (libs/common/src/vault/models/view/cipher.view.ts:57). No server/API work needed.
• Blast radius is small. Each client has its own vault-list component — no shared-lib refactor required. Stage 1 touches only apps/desktop/src/vault/app/vault-v3/ plus a new helper in CipherViewLikeUtils (following the existing isArchived/isDeleted dual-branch pattern for CipherView | CipherListView).
• I18n key exists. dateCreated → "Created" already exists in apps/desktop/src/locales/en/messages.json.
• No existing internal WIP that I could find. No open GitHub issue tracks this (only a closed favourites-sort bugfix, [PM-16194] Do not sort Favorite ciphers by last used date #12466), and no open PR references these community threads.

What I'm asking for

A maintainer 👍 or 👎 on the staged approach, plus answers (or pointers to answers) on the four questions above. Once I have direction, I'll open the Stage 1 desktop PR linking back to this discussion.

Thanks for your time on this — happy to adjust the scope or approach based on your feedback.

Hi maintainers — per the contributing guide I'm opening this as a Discussion to get your input on a UX change before writing code. CLA is signed.

The change, in one sentence

Let users sort their vault list by creation date (newest first / oldest first), so they can find a recently-added item by scrolling chronologically when they can't remember its name.

Why this, why now

Users frequently sign up for a service, save it to Bitwarden, and later can't remember the exact name to search for it. Competing managers (1Password, KeePass) solve this with a date-sort. It's the reason I'm considering switching to Bitwarden from 1Password.

Community demand has been consistent and unanswered for nearly 8 years:

• [Sort items by date of modification, addition, last use, etc](https://community.bitwarden.com/t/sort-items-by-date-of-modification-addition-last-use-etc/2484) — October 2018, 61+ likes on the OP, 12+ pages of replies, now locked
• [Sort Entries by "Recently Added" and "Recently Modified"](https://community.bitwarden.com/t/sort-entries-by-recently-added-and-recently-modified/80104)
• [Bitwarden Browser Extension Vault Sorting](https://community.bitwarden.com/t/bitwarden-browser-extension-vault-sorting/72289)
• [Add sort by for objects in vault](https://community.bitwarden.com/t/add-sort-by-for-objects-in-vault/36121)
• [Sort Vault Items by Revision Date Using the CLI](https://community.bitwarden.com/t/sort-vault-items-by-revision-date-using-the-cli/48108)

A third party even [published a workaround blog post](https://shkspr.mobi/blog/2024/02/howto-sort-bitwarden-passwords-by-date/) piping CLI exports through jq, which suggests the demand is real enough that users build their own tools.

Related proposal

Kevin Rossen proposed a similar "Recent Items" feature for iOS in org-level discussion [#16874](https://github.com/orgs/bitwarden/discussions/16874) (Oct 2025, currently labelled pr-proposal-stage2-product-review and awaiting review). This proposal is the counterpart for the clients-repo targets (desktop/web/browser) and doesn't depend on or duplicate Kevin's iOS work — the two together would give users consistent chronological access across every client.

What I'd like your input on

Four UX decisions I'd rather land with you before I write code, rather than discover in PR review:

1. Column vs. sort menu on desktop/web
Desktop and web already use bitSortable column headers for Name and Owner. My instinct is to add a "Created" column (responsive-hidden on narrow viewports, matching the existing Owner column pattern). The alternative is a sort-selector menu/dropdown that doesn't show a date column. Column feels more consistent with existing patterns and gives users an at-a-glance date. Your preference?

2. Creation date vs. revision date as the first option
I'm proposing creation date first because it matches the "find my recent signup" user story directly. Revision date is also useful (sort by recently-modified) and could be a follow-up toggle. Is there a reason to prefer revision date, or to ship both at once?

3. Staged client rollout
I'd like to ship in this order to keep each PR small and reviewable:

Stage	Client	Effort
1	Desktop	Small — follows existing SortFn/bitSortable pattern
2	Web	Small — near-identical to desktop
3	Shared persistence	Add VAULT_SORT_ORDER under VAULT_SETTINGS_DISK so sort choice persists
4	Browser extension	Medium — different paradigm, wants design input
5	Mobile (iOS/Android)	Separate repos, out of scope for clients

Stages 1–2 are almost copy-paste once the pattern's agreed. Stage 4 is where real design discussion is needed — the popup has no column headers and groups by cipher type, so "where does the sort toggle live in a 360px popup" is a UX call I'd want you to make. Is the staged sequencing reasonable, or would you prefer a single coordinated PR across desktop+web?

4. Grouping / timeline view (later follow-up)
A natural next step is section headers that group items by month/year (like a phone photo timeline), so users can skim "January 2025" → "February 2025" → etc. This would be a separate, larger proposal after stages 1–3 land — flagging it now so you know the direction but not asking you to decide on it today.

Technical notes

• Data is already there. CipherView.creationDate: Date is populated on the client (libs/common/src/vault/models/view/cipher.view.ts:57). No server/API work needed.
• Blast radius is small. Each client has its own vault-list component — no shared-lib refactor required. Stage 1 touches only apps/desktop/src/vault/app/vault-v3/ plus a new helper in CipherViewLikeUtils (following the existing isArchived/isDeleted dual-branch pattern for CipherView | CipherListView).
• I18n key exists. dateCreated → "Created" already exists in apps/desktop/src/locales/en/messages.json.
• No existing internal WIP that I could find. No open GitHub issue tracks this (only a closed favourites-sort bugfix, [PM-16194] Do not sort Favorite ciphers by last used date #12466), and no open PR references these community threads.

What I'm asking for

A maintainer 👍 or 👎 on the staged approach, plus answers (or pointers to answers) on the four questions above. Once I have direction, I'll open the Stage 1 desktop PR linking back to this discussion.

Thanks for your time on this — happy to adjust the scope or approach based on your feedback.

[github-actions[bot]]

✨ Thank you for your code contribution proposal! While the Bitwarden team reviews your submission, we encourage you to check out our contribution guidelines.

Please ensure that your code contribution includes a detailed description of what you would like to contribute, along with any relevant screenshots and links to existing feature requests. This information helps us gather feedback from the community and Bitwarden team members before you start writing code.

To keep discussions focused, posts that do not include a proposal for a code contribution will be removed.

• 💡 For feature requests and general discussion, please visit the Bitwarden Community Forums.
• ℹ️ For questions and support, visit the Bitwarden Help Center.
• 🐛 To report a potential bug, please visit the corresponding repo. Server | Clients | iOS | Android

Thank you for contributing to Bitwarden!