Significant-Gravitas/AutoGPT · error · HTTPException

Session {session_id} not found or access denied

Error message

Session {session_id} not found or access denied

What it means

A 404 from DELETE /chat/sessions/{session_id}: delete_chat_session() returned falsy, meaning the session does not exist or is not owned by the requesting user/organization. The message deliberately conflates 'not found' and 'access denied' to avoid leaking the existence of other users' sessions.

Source

Thrown at autogpt_platform/backend/backend/api/features/chat/routes.py:759

    Delete a chat session.

    Permanently removes a chat session and all its messages.
    Only the owner can delete their sessions.

    Args:
        session_id: The session ID to delete.
        user_id: The authenticated user's ID.

    Returns:
        204 No Content on success.

    Raises:
        HTTPException: 404 if session not found or not owned by user.
    """
    deleted = await delete_chat_session(session_id, user_id, organization_id=ctx.org_id)

    if not deleted:
        raise HTTPException(
            status_code=404,
            detail=f"Session {session_id} not found or access denied",
        )

    # Best-effort cleanup of the E2B sandbox (if any).
    # sandbox_id is in Redis; kill_sandbox() fetches it from there.
    e2b_cfg = ChatConfig()
    if e2b_cfg.e2b_active:
        assert e2b_cfg.e2b_api_key  # guaranteed by e2b_active check
        try:
            await kill_sandbox(session_id, e2b_cfg.e2b_api_key)
        except Exception:
            logger.warning(
                "[E2B] Failed to kill sandbox for session %s", session_id[:12]
            )

    return Response(status_code=204)

View on GitHub (pinned to 9c8bb5550f)

Solutions

1. Treat 404 on delete as success in idempotent clients (the session is gone either way) — drop it from local state and move on.
2. Otherwise refresh the session list and delete by a live id.
3. If the session should be deletable, verify the authenticated user and org context match the session's owner fields in the DB.

Example fix

// before
if (res.status !== 204) throw new Error('delete failed');  // 404 on retry crashes

// after
if (res.status === 404) { removeSessionFromState(id); }  // idempotent: already gone
else if (res.status !== 204) throw new Error('delete failed');

const live = sessions.some(s => s.session_id === id);
if (!live) { removeSessionFromState(id); return; } // idempotent skip
await deleteSession(id);

try {
  await deleteSession(id);
} catch (e) {
  if (e.status === 404) { removeSessionFromState(id); return; } // already gone: treat as success
  throw e;
}

When it happens

Trigger: DELETE /chat/sessions/{id} where the id was already deleted, never existed, belongs to another user, or belongs to a different organization than the request context (org_id is part of the ownership scoping).

Common situations: Double-delete: user clicks delete in two tabs or the client retries after a first success; stale session list after deletion elsewhere; wrong org context header/token for a session created in another org.

Understand the failure class

• Authentication and authorization failures — expired tokens, bad credentials, and missing scopes.

Related errors

• Session {session_id} not found.
• codex_credential_not_found
• Expert not found
• Title must not be blank
• codex_builder_session_unsupported

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