Bitwarden Windows, Latest Version - App dont show any entry

[seals187]

1. Update / Install the latest Windows Bitwarden Version
2. Open Bitwarden
3. No entries are shown, everything is empty

[Profex]

Can confirm this with version 2026.7.0. Rolling back to Bitwarden Client 2026.6.1 resolves the issue.

Update: To temporary disable automatic Bitwarden Client updates until the issue is resolved you can set system environment variable ELECTRON_NO_UPDATER=1

[tom27052006]

Already fixed in #7434, but the fix has not yet been included in the latest stable release. @BlackDex @dani-garcia

btw: Same problem in the new browser extension (2026.7.0)

[coolaj86]

I believe I'm having the same issue, in the 2026.7.0 extension console I get this error:

bitwarden_wasm_internal_bg.js:6830 Uncaught Error: Error: invalid type: JsValue(Object({"fido2Credentials":[],"fields":[],"name":"...","notes":null,"password":"...","passwordHistory":[],"passwordRevisionDate":null,"totp":null,"uri":"...","uris":[{"match":null,"uri":"...","uriChecksum":"..."}],"username":"..."})), expected a string

I do not have this problem in the 2026.6.1 version of the Chromium extension.

[BlackDex]

Probably already fixed using the :testing tagged container images.

[coolaj86]

I got it working with the :testing binaries: bitwarden/clients#22013 (comment)

Update: :testing-alpine is likely a better choice since it will work everywhere regardless of distro.

[multi6810]

Can confirm too :testing fixed this issue on the firefox and chrome extension 2026.7.0

[aphedges]

I got Firefox extension 2026.7.0 to work with :testing-alpine, but I needed to manually initiate a sync to pull the fixed data.

[coolaj86]

I didn't know there was a :testing-alpine. Since this is a Rust project that should just mean that it will work everywhere (Ubuntu, Fedora, etc) without having to deal with version and dependency conflicts, regardless of the distro.

[alefsanderribeiro]

Same issue here, but with the browser extension v2026.7.0 (Edge/Chrome) self-hosted Vaultwarden 1.36.0.

Console error:

Uncaught Error: Error: invalid type: JsValue(Object({...cipher...})), expected a string

The WASM SDK 0.2.0 (shipped in extension v2026.7.0) fails to deserialize cipher JSON where autofillOnPageLoad, passwordRevisionDate, notes, totp are null, and uri + uris coexist.

Temporary fix: downgrade to browser extension v2026.6.0.

Relevant PR: bitwarden/clients#21233 (SDK update to 0.2.0)

[rongwei-lab]

Confirmed on an independent self-hosted deployment.

• Server: Vaultwarden 1.36.0 (Web Vault 2026.4.1), Docker + SQLite, behind an Nginx reverse proxy.
• Symptom: authentication succeeds and /api/sync returns HTTP 200 with a normal-sized payload (~690 KB), but the Chromium/Edge browser extension remains on the infinite skeleton loading state and shows no entries.
• The behavior is unchanged when bypassing the edge/CDN proxy, so this is not a proxy or transport failure.
• Rolling the extension back to the working June 2026 build (reported as 2026.06.01 / 2026.6.x) restores the vault entries immediately.

This matches the client-side deserialization regression described here and the fix in #7434: the current stable server still emits the legacy cipher data object, while the newer client reuses data for blobs and expects a string. Please include #7434 in the next stable release.

No domain, credentials, vault contents, or identifiers are included in this report.

[Thinkscape]

I can reproduce what appears to be the same regression in the browser extension (macOS Zen, Firefox-based):

• Vaultwarden: 1.36.0 (current release; bundled Web Vault 2026.4.1)
• Bitwarden browser extension: 2026.7.0
• Result: the Vault tab remains on “Loading vault” after the account and organisation keys have unlocked successfully.

The extension DevTools exception is:

Error: invalid type: JsValue(Object(...))

The object is a normal encrypted login-shaped payload (for example name, password, uris, fields, and an empty fido2Credentials array); no plaintext is involved.

I inspected the extension’s local encrypted-cipher state without exposing any vault values. All 2,016 cached ciphers have CipherData.data as an object. In 2026.7.0, Cipher.toSdkCipher() passes this through as data: this.data, but the WASM SDK expects data to be a string and throws before it can render the list. The previous signed AMO build, 2026.6.1, instead passes data: undefined and does not have this failure.

This change appears related to Bitwarden clients PR #20765 (PM-32696, blob-encryption support): bitwarden/clients#20765

Could this be assessed as a Vaultwarden/client compatibility issue? A workaround is downgrading the extension to 2026.6.1; redeploying Vaultwarden or clearing the local vault cache does not address the schema mismatch.

[reY2ox]

I also noticed the same issue, including with the latest Firefox browser extension and the latest Bitwarden app on macOS. After downgrading, it works again.