Significant-Gravitas/AutoGPT · error · HTTPException

Username mismatch: authenticated as a different user

Error message

Username mismatch: authenticated as a different user

What it means

In _upgrade_existing_credential, if both the existing credential and the newly obtained one carry a username and they differ, HTTP 400 'Username mismatch: authenticated as a different user' is raised. Scope upgrade is only valid when the same external account re-consents; merging tokens from a different external account into an existing credential would silently switch whose data the credential accesses.

Source

Thrown at autogpt_platform/backend/backend/api/features/integrations/router.py:1123

            detail="Credential to upgrade not found",
        )
    if existing.is_managed:
        raise HTTPException(
            status_code=status.HTTP_400_BAD_REQUEST,
            detail="Managed credentials cannot be upgraded",
        )
    if not provider_matches(existing.provider, new_credentials.provider):
        raise HTTPException(
            status_code=status.HTTP_400_BAD_REQUEST,
            detail="Credential provider does not match the requested provider",
        )

    if (
        existing.username
        and new_credentials.username
        and existing.username != new_credentials.username
    ):
        raise HTTPException(
            status_code=status.HTTP_400_BAD_REQUEST,
            detail="Username mismatch: authenticated as a different user",
        )

    # Operate on a copy so the caller's ``new_credentials`` object is not
    # mutated out from under them.  Every caller today immediately discards
    # or replaces its reference, but the implicit-merge path in
    # ``_merge_or_create_credential`` reads ``credentials.scopes`` before
    # calling into us — a future reader after the call would otherwise
    # silently see the overwritten values.
    merged = new_credentials.model_copy(deep=True)
    merged.id = existing.id
    merged.title = existing.title
    merged.scopes = list(set(existing.scopes) | set(new_credentials.scopes))
    merged.metadata = {
        **(existing.metadata or {}),
        **(new_credentials.metadata or {}),
    }

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Sign out of the other account at the provider (or use an incognito window) and redo the upgrade flow, ensuring you consent as the same account that owns the existing credential.
  2. If you intentionally want the other account, create a new credential instead of upgrading the existing one.
  3. Check the existing credential's username field first so you know which account to authenticate as.
Defensive patterns

Strategy: validation

Validate before calling

# Show the user which account must re-consent before redirecting
existing = await get_credential(existing_cred_id)
if existing.get("username"):
    display(f"Re-authorize as {existing['username']} to upgrade scopes")

Prevention

When it happens

Trigger: User initiates 'upgrade scopes' on a credential for account alice@provider, but during the OAuth consent step signs in as bob@provider (different account selected at the provider, or browser logged into another account). The callback detects existing.username != new_credentials.username and aborts the merge.

Common situations: Shared workstations where the browser's provider session belongs to a different account; user switching company accounts mid-flow; provider defaulting to a personal account when the credential was created with a work account.

Understand the failure class

Related errors


AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14). Data as JSON: /api/errors/9733479654a725d9. Report an issue: GitHub.