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:
- User logs into pgAdmin using OIDC.
- The account is auto-created (
OAUTH2_AUTO_CREATE_USER = True).
- Some users eventually begin experiencing frontend issues.
- The backend logs
Failed to decrypt the saved password with UTF-8 decoding errors.
- 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.
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:
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:
OAUTH2_AUTO_CREATE_USER = True).Failed to decrypt the saved passwordwith UTF-8 decoding errors.The issue only affects a subset of users.
Expected behavior
If pgAdmin encounters an encrypted password that cannot be decrypted, I would expect either:
rather than leaving the user in a permanently broken state.
Error message
Example:
Other affected users report different byte values, for example:
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)
sha256:40fa840c5bb7c8463957f1255b01283732c2d8c9396a956d180f8e6c296753b3)Additional context
CONFIG_DATABASE_URI) instead of the default embedded SQLite database.OAUTH2_AUTO_CREATE_USER = True.a-z), making it unlikely that special characters or Unicode passwords are contributing to the problem.If useful, we can provide our OAuth2 configuration (minus secrets), additional logs, or information about our PostgreSQL-backed pgAdmin configuration database.