OIDC users intermittently fail with "Failed to decrypt the saved password" and cannot be recovered by recreating the user

Describe the bug

Some (but not all) users consistently experience frontend errors after logging into pgAdmin using OIDC/OAuth2.

The backend logs contain errors similar to:

2026-07-03 11:00:39,895: ERROR pgadmin: Failed to decrypt the saved password.
Error: 'utf-8' codec can't decode byte 0xc4 in position 0: invalid continuation byte

The failing byte is not always 0xc4; it varies between affected users, but is consistently a high-value byte (>= 0x80).

The issue persists for affected users even after deleting the user from the pgAdmin configuration database and allowing them to be recreated via OIDC. Other users on the same deployment continue to work normally.

To Reproduce

Unfortunately, we have not found a deterministic way to reproduce the issue.

Observed behavior:

1. User logs into pgAdmin using OIDC.
2. The account is auto-created (OAUTH2_AUTO_CREATE_USER = True).
3. Some users eventually begin experiencing frontend issues.
4. The backend logs Failed to decrypt the saved password with UTF-8 decoding errors.
5. The affected user remains broken even after deleting and recreating the pgAdmin user.

The issue only affects a subset of users.

Expected behavior

If pgAdmin encounters an encrypted password that cannot be decrypted, I would expect either:

• the corrupted saved password to be discarded and the user prompted again, or
• the invalid saved password entry to be ignored,

rather than leaving the user in a permanently broken state.

Error message

Example:

2026-07-03 11:00:39,895: ERROR pgadmin: Failed to decrypt the saved password.
Error: 'utf-8' codec can't decode byte 0xc4 in position 0: invalid continuation byte

Other affected users report different byte values, for example:

Error: 'utf-8' codec can't decode byte 0xb9 in position 1: invalid start byte

The byte value changes, but it is always a relatively high byte rather than valid UTF-8.

Screenshots

None available.

Desktop (please complete the following information)

• OS: Kubernetes (Linux container)
• pgAdmin version: 9.16
• Mode: Server
• Browser: Chrome and Firefox (same behavior)
• Package type: Official Container image (sha256:40fa840c5bb7c8463957f1255b01283732c2d8c9396a956d180f8e6c296753b3)

Additional context

• Single pgAdmin pod (not a multi-replica deployment).
• pgAdmin is configured to use an external PostgreSQL database as its configuration database (CONFIG_DATABASE_URI) instead of the default embedded SQLite database.
• Authentication is via OIDC/OAuth2 with OAUTH2_AUTO_CREATE_USER = True.
• The problem is user-specific rather than deployment-wide.
• Other users on the same deployment continue to work normally.
• Clearing the browser cache does not help.
• Using a different browser does not help.
• Restarting the pgAdmin pod does not help.
• Deleting the affected pgAdmin user from the configuration database and allowing it to be recreated via OIDC does not help.
• The issue also persists after changing both the master password and the PostgreSQL server password to newly generated passwords containing only simple ASCII letters (a-z), making it unlikely that special characters or Unicode passwords are contributing to the problem.
• Since the affected user can be completely recreated and the issue still persists, it appears that either some user-specific state is not being removed or the decryption failure has another underlying cause.

If useful, we can provide our OAuth2 configuration (minus secrets), additional logs, or information about our PostgreSQL-backed pgAdmin configuration database.

No files, tests, or entry points are named. Start by tracing the saved-password decryption path from the reported backend error through OIDC user creation and deletion, comparing affected and recreated users. Done means the user-specific state or underlying cause is identified and the invalid-password behavior is verified for affected users.