Add "Share via Send" action to vault items (one-click, UI-only)

[babyhuey]

I would like to propose adding a "Share via Send" action to the vault item context menu in the web, desktop, and browser-extension clients. Clicking it would open the existing Send composer pre-filled with the item's credentials, so users no longer have to copy each field by hand into a text Send.

A working branch (web, desktop, browser; all client tests green; webpack build green) is here for concrete reference: https://github.com/babyhuey/clients/tree/share-via-send

Context

Several long-standing community threads have asked for exactly this UX, most recently Send a password from vault. The canonical vault-item-sharing thread (open since 2018) is broader and architecturally fraught; this proposal is intentionally narrower.

What I am proposing (v1)

A new menu entry, "Share via Send", on the vault item action menu. Clicking it:

1. Reprompts when the cipher requires it.
2. Honors the DisableSend policy (toast + bail before any credential plaintext leaves the menu).
3. Builds a SendView from the cipher's username, password, URI, and notes, with conservative defaults:
   • TOTP secret excluded (sharing the seed grants ongoing access via the regenerating code, qualitatively different from sharing a static password).
   • Custom fields excluded (these commonly hold backup codes).
   • Body marked hidden, deletion in one day, single view.
4. Opens the existing Send composer pre-filled. The user can edit, opt back into TOTP/custom fields, relax the defaults, or just save.

The user controls the final Send. The pre-fill is a convenience layer; the data path is identical to manual copy/paste.

What I am not proposing

• Not a replacement for the long-asked Vault Item Sharing feature. That ask is about persistent shared state between two Bitwarden accounts; this is one-time, ephemeral, and the recipient does not need an account.
• Not a new sharing primitive. It's a UX shortcut on top of SendType.Text and the existing Send composer.
• No server-side changes. The Send API surface is unchanged.

Suggested direction (matches the working branch)

• New { type: "shareViaSend"; item: C } variant on the existing VaultItemEvent discriminated union in libs/vault.
• New cipherToSendTextView(cipher, options) pure helper in libs/common/src/tools/send, unit-tested in isolation.
• Optional initialView?: SendView field on SendFormConfig. In add mode, DefaultSendFormService routes it through originalSendView so existing form components patch their controls without per-component changes.
• Browser uses an in-memory single-shot PendingSendDraftService with a caller-issued token (passed as a query param) so credential plaintext never travels through URLs and a cancelled share-via-send navigation cannot leak its draft into a later "New Send" click.
• Web and desktop reuse SendAddEditDialogComponent.open / openDrawer. Browser navigates to the existing /add-send route.

Total diff in the working branch: 21 files, 590 insertions. All five client app test groups (libs, browser, web, desktop, cli) and the full test:types strict-mode pass.

Questions for the team

1. Security posture. Is the conservative-default approach (TOTP and custom fields excluded, body hidden, 1 view, 1 day) acceptable, or are there objections to credentials flowing into Send via UI affordance vs. manual copy/paste? The data path is identical; only convenience differs.
2. Policy surface. The branch gates on areSendsAllowed (via SendPolicyService). Should there also be a separate, narrower policy for "Disable Share via Send for org-owned items" so admins can turn off the convenience without disabling Sends entirely, or is the existing policy sufficient?
3. Appetite. Is there interest in a community PR for this, given that there appears to be in-flight staff work on adjacent Send features (Bitwarden Receive, Send policies/event logs)? I would rather not duplicate or pre-empt staff work.

Happy to adjust scope based on feedback before opening the PR.

[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!