Module receive 

bw receive / bw send receive — access a Bitwarden Send from a url.

This is the only Send flow that runs without a logged-in user: the send’s content is decrypted with a key derived purely from the URL fragment ([bitwarden_send::SendAccessKey]), never from the account key store. Because the link can point at any deployment, the command builds its own [PasswordManagerClient] per invocation from URLs derived off the link itself (see resolve_urls) rather than reusing the session client — a self-hosted receive link must not have its password hash sent to Bitwarden cloud identity, and vice versa.

Both bw receive <url> and bw send receive <url> are the same command; their arg structs are field-identical and both funnel into run_receive.

PM-40120: the legacy CLI’s version of this bug mints against its configured environment but can leak the resulting real token to an attacker-controlled host on a follow-up fetch. The decided fix (2026-08-17) is that a Send access token must never be requested from anywhere but the server named in the Send link itself. resolve_urls already does this unconditionally for both the API and identity origin, so the mint and fetch here always target the same resolved host and a token can never cross the kind of domain boundary PM-40120 tracked. A link naming an attacker-controlled host still sends that host a password hash if the user proceeds — but per the decided fix, that’s the token’s only valid target, not a leak to a second, different host.

Structs

CloudRegion 🔒

ReceiveInputs 🔒

The flags bw receive and bw send receive share, normalized into one struct so the two entry points cannot drift apart.

Constants

CLOUD_HOSTS 🔒

The Bitwarden cloud deployments whose Send links do not carry their API host.

Functions

access_with_email_otp 🔒

Email-OTP-protected Sends: the email request is what makes the server send the code, so the expected outcome of the first call is an email_and_otp_required error, not a token.

access_with_password 🔒

Password-protected Sends: resolve the password from flags/env/file/prompt, run it through the same PBKDF2 recipe bw send create --password used, and exchange it for a token.

attempt_access 🔒

Negotiate a send-access token, prompting for whatever credential the server says the Send needs. Mirrors the legacy attemptAccess: ask with no credentials first and branch on the typed send_access_error_type the server returns.

can_interact 🔒

Whether we may prompt the user.

download_bytes 🔒

GET a pre-signed blob URL with the client’s shared HTTP stack (so proxy and TLS settings apply), mirroring legacy’s apiService.nativeFetch.

invalid_grant_type 🔒

Same idea as invalid_request_type, but for the invalid_grant response shape (used to detect an unknown Send id or an invalid password hash).

invalid_request_type 🔒

Extracts the typed send_access_error_type from an invalid_request response, or None if err isn’t that shape. attempt_access and access_with_email_otp both need to branch on this one sub-field of a deeply nested error enum; centralizing the match here keeps those call sites down to a single Some(...) => ... comparison instead of repeating the full pattern.

parse_send_url 🔒

Extract (send_id, url_b64_key) from the last two #-fragment segments.

password_from_args 🔒

Non-interactive half of resolve_password, split out so the precedence is unit-testable.

prompt_email 🔒

prompt_otp 🔒

prompt_password 🔒

Prompt for the Send’s password. inquire renders to stderr, so bw receive <url> > out.txt still captures only the Send’s content — the same reason legacy passes output: process.stderr to inquirer.

render_access 🔒

Fetch the Send with the negotiated token, decrypt it with the URL key, and render it.

request_token 🔒

resolve_password 🔒

Resolve the Send’s password, prompting when it wasn’t supplied and the session is interactive. Mirrors legacy’s handlePasswordAuth precedence exactly.

resolve_urls 🔒

Resolve the API and identity base URLs to talk to for a given Send link, plus whether that host is trusted.

run_receive 🔒

Entry point for super::ReceiveArgs’s BwCommand impl, reached both from the top-level bw receive command and from SendCommands::Receive (bw send receive), which reuses the same arg struct rather than a hand-synced copy.

same_origin 🔒

true when configured denotes the same origin as origin (already an ASCII origin serialization). Falls back to a string compare for values that aren’t parseable URLs, so a hand-edited config.json still matches.

save_file_send 🔒

Download, decrypt, and save a file-type Send’s blob.

token_error 🔒

Surface a token-negotiation failure we have no specific message for. The error’s Debug carries the server’s error_description, which is diagnostic and never contains send content or credentials.

trimmed 🔒