[Bug] Desktop repeatedly opens `/dub` attribution URL because the route returns 404

[Hasif50]

Summary

DevSwarm Desktop 2.4.0 repeatedly opens a short-lived Dub attribution URL in the system browser after login/session renewal. The hard-coded https://devswarm.ai/dub route currently returns HTTP 404, so the intended callback never completes and the app retries at later session renewals.

Environment

• DevSwarm Desktop: 2.4.0
• Platform: Windows 11 with WSL
• Production API callback: https://api.devswarm.ai/user/dub-id

Observed behavior

1. A login or silent session renewal stores the session.

2. The desktop app checks the current user.

3. When dubCheckedAt is null, it obtains a setter JWT and opens:

   https://devswarm.ai/dub?token=[REDACTED]&callback=https%3A%2F%2Fapi.devswarm.ai%2Fuser%2Fdub-id

4. /dub returns the generic DevSwarm 404 page and does not execute the callback.

5. Because dubCheckedAt remains null, the browser handoff happens again on a later session renewal. In the observed installation, the authentication refresh pattern was approximately every six hours.

Correlated evidence

• Session renewal logged at 2026-07-30 14:54:00 +08:00.
• The corresponding redacted setter token was issued at 14:54:01 and expired at 14:57:01 (180-second lifetime).
• A fresh request to the bare https://devswarm.ai/dub endpoint still returns HTTP 404.
• Inspection of the packaged desktop code shows that session storage calls dubIdResolutionService.resolveDubId(). The service fetches /user, checks dubCheckedAt, fetches /user/dub-id-setter-jwt, and invokes Electron shell.openExternal().
• Errors in this resolver are swallowed, so the normal app log does not explain the browser launch or failed completion.

No JWT, signature, user UUID, local username, or account credential is included in this report.

Expected behavior

• The attribution flow should complete once or support an explicit opt-out.
• A missing/unavailable web handler must not cause repeated unsolicited browser launches.
• Silent authentication renewal should not repeatedly open an external browser.

Security and privacy considerations

The setter JWT is scoped to SET_DUB_ID and short-lived, but it is placed in the query string. The current generic 404 page also loads marketing/analytics scripts. A token-handling route should avoid unrelated trackers and prevent the complete URL from reaching analytics, referrers, logs, or support reports.

Suggested remediation

• Restore a dedicated /dub handler as an immediate server-side fix for existing 2.4.0 clients.
• Make the callback idempotently mark the attribution check complete, including when no dub_id cookie exists or the user opts out.
• Replace the query-string JWT with a one-time code or URL fragment, and hard-code/allowlist the callback rather than accepting an arbitrary callback URL.
• Prompt once instead of launching automatically on each session renewal; add bounded retry/backoff and persist failure state.
• Log a sanitized status/error without recording the tokenized URL.
• Add an explicit referral-attribution privacy control.

Verification criteria

• Bare /dub returns the intended handler instead of 404.
• One successful completion or opt-out prevents future browser launches.
• Expired/replayed tokens fail safely.
• Missing cookies, content blockers, or network errors cannot create an endless retry loop.
• No complete tokenized URL is captured by analytics or logs.

[AdamFiser]

same for me

[trevordilley]

@Hasif50 / @AdamFiser this should be addressed in version 2.5.0+!