ProxmoxMCP-Plus v0.5.24

Release date: 2026-10-01

OAuth configuration

• Use MCP_API_KEY from the process environment as the browser-consent
  credential. Remove MCP_OAUTH_KEY_VERSION and database fingerprint/version
  synchronization; a legacy environment variable is ignored.
• Keep registered OAuth clients, authorization codes, access/refresh tokens and
  login-failure state in PostgreSQL. Changing the browser-consent key no longer
  invalidates those credentials. Use explicit revocation for compromised tokens.
• Leave an existing proxmox_mcp_oauth_metadata table and its values untouched.
  The new runtime does not create, read, update or delete that table. This avoids
  breaking old workers' consent queries, dependent views and same-key rollback.

Includes PR #141.

Upgrade and key rotation

Install proxmox-mcp-plus==0.5.24 or pull
ghcr.io/rekklesna/proxmoxmcp-plus:0.5.24.

Back up the OAuth database before upgrading. No manual SQL migration is required.
For deployments using the same key, existing OAuth credentials are preserved.

To change the browser-consent key, stop every MCP instance using the issuer,
update MCP_API_KEY, restart all instances with the same new value, then restore
traffic. Running instances do not reload environment changes. There is no
database guard to reject stale instances: during a rolling key change, an old
instance still accepts the old key, and consent requests routed between instances
with different keys fail. Pending transactions signed with the previous key are
rejected after all instances have restarted. Issued OAuth credentials continue
their normal expiry/revocation lifecycle.

For rollback, keep the original key and legacy key version. After a key change,
legacy metadata still describes the old key; restore the old configuration or
follow the old version's rotation procedure, which invalidates OAuth state.
Only remove the legacy metadata table manually once old instances and rollback
requirements are retired. It can still contain the previous key's verifier.

Validation

PostgreSQL regressions cover fresh databases, preservation of legacy metadata and
all OAuth state categories, repeated/concurrent startup, schema failure recovery,
old-worker queries, dependent views, cross-instance authorization/token exchange,
replay rejection, and API-key change semantics. The actual old store implementation
was used to reproduce the original table-deletion failure and verify the repair
and same-key rollback. CI checks Python 3.11/3.12, coverage, Ruff, mypy, build and
release metadata, dependency auditing, and CodeQL.