[bug]: Self-hosted Desktop App login stuck on spinner — device-token handoff returns 200 but session never activates (me query stays 401)

Is there an existing issue for this?

• I have searched existing issues and this bug hasn't been reported yet

Platform

Desktop App

Browser

Chrome

Operating System

Linux

Bug Description

Environment

• Hoppscotch Desktop App: v26.8.0 (installed via official .deb, hoppscotch package)
• Hoppscotch Backend / Frontend / Admin: v2026.6.0 (self-hosted Community Edition, Docker containers)
• OS: Ubuntu 26.04.1 LTS (amd64)
• Browsers tested: Firefox (official Mozilla .deb, non-snap) and Google Chrome (official .deb) — identical failure on both, ruling out a browser-specific cause.
• Deployment: hoppscotch/hoppscotch-backend, hoppscotch/hoppscotch-frontend, hoppscotch/hoppscotch-admin, all 2026.6.0, behind a reverse proxy at https://selfhost.example.com.

Description

Logging into the Desktop App against a self-hosted instance via the email magic-link flow never completes: the app shows a spinner on the login screen indefinitely, even though the backend confirms the email link server-side and the token handoff to the app's local loopback server succeeds at the network level.

Steps to reproduce

1. Self-host Hoppscotch Backend/Frontend/Admin 2026.6.0 behind a custom domain, with WHITELISTED_ORIGINS including the desktop app's Tauri origin (app://<domain_with_underscores>) — confirmed present and correctly formatted in our config.
2. Open Hoppscotch Desktop, point it at the self-hosted instance, choose "Login with Email".
3. App opens the system browser to the login page; submit email, receive magic-link email.
4. Click the magic-link in the email → browser confirms "You're logged in, you can go back to the app now."
5. Switch back to the Desktop App: it remains on the login screen with an infinite spinner.

Expected behavior

After step 4, the Desktop App should detect the completed login and transition to the logged-in state.

Actual behavior

• Confirmed (via ss -tlnp) the desktop app process has an active loopback listener, e.g. 127.0.0.1:15000.
• Confirmed (via browser DevTools Network tab) that the browser page issues: GET http://localhost:<port>/device-token?access_token=<jwt>&refresh_token=<jwt> → Status 200 OK, response body null, no CORS error, no red console errors.
• Despite the 200 response, the app's own subsequent GraphQL me query (captured via the app's own DevTools) still returns:

  {
    "errors": [{
      "message": "Unauthorized",
      "extensions": {
        "code": "UNAUTHENTICATED",
        "stacktrace": [
          "UnauthorizedException: Unauthorized",
          "    at GqlAuthGuard.handleRequest (.../node_modules/@nestjs/passport/dist/auth.guard.js:60:30)",
          "    ...",
          "    at JwtStrategy.authenticate (.../node_modules/passport-jwt/lib/strategy.js:96:21)"
        ]
      },
      "originalError": { "message": "Unauthorized", "statusCode": 401 }
    }],
    "data": null
  }
  

• Inspecting the app's local persistence log around the time of the /device-token call shows store writes for gqlHistory, restHistory, restCollections, gqlCollections, settings, globalEnv — but no store write related to auth/session/token appears at any point, suggesting the /device-token handler on the app side may not be persisting the received tokens into the app's active auth/session store, even though it returns 200.
• This reproduces consistently regardless of browser (tested Firefox and Chrome side by side, same OS, same backend, same result), which rules out browser/CORS/protocol-handler causes and points to the app-side (or backend-side) handling of the /device-token payload for self-hosted (non-app.hoppscotch.io) instances.

Additional context

• WHITELISTED_ORIGINS on the backend already includes the correctly-formatted desktop origin (app://<domain_with_underscores>), so this does not appear to be the origin-whitelist issue described in other reports (e.g. #6389, #5186, #4922).
• Happy to provide additional logs/HAR captures if useful — let me know what would help narrow this down (e.g., is there a client-side event/poll expected after /device-token that isn't firing, or a version mismatch between the 2026.6.0 backend's token payload and what 26.8.0 desktop expects?).

Deployment Type

Self-hosted (on-prem deployment)

Version

v26.8.0