bug: token endpoint not being called after expiring

[Freedisch]

• fix token expiration
• moved refreshToken to localstorage for persistante login
• add login via right sidePanel
• add report issue

---

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
synapseai	Ready	Preview, Comment	May 26, 2026 8:53am

[devin-ai-integration]

Cleanup: _activeToken and API_URL are now dead code

After this PR, all API calls in popup.js go through chrome.runtime.sendMessage instead of direct fetch. This means:

• _activeToken (line 4) is assigned on line 86 and cleared on logout (line 153), but is never read anywhere. It was previously used as the Authorization header in the MCP token fetch, but that now goes through the background too.
• API_URL (line 2) was used for the direct fetch calls to /v1/memory and /v1/mcp/token. Both are removed in this PR, leaving the constant unused.

Both should be removed to avoid confusion about whether popup.js still makes direct API calls.

[devin-ai-integration]

Nit: Missing fallback — inconsistent with token field

token gets a || '' fallback (line 11) so callers always see a string. refreshToken has no fallback, so it can be undefined when no refresh token is stored. This is a minor inconsistency — consider session.refreshToken || '' for symmetry, or add a comment explaining why undefined is intentional here (e.g. so !refreshToken correctly triggers the "Not logged in" guard in rotateAccessToken).

[devin-ai-integration]

Edge case: GENERATE_MCP_TOKEN silently fails if the service worker is restarted mid-call

This is a general concern for the new message-passing architecture, but it's most user-visible here. If the Manifest V3 service worker is suspended between the popup sending GENERATE_MCP_TOKEN and apiFetch completing, chrome.runtime.sendMessage can reject with "Could not establish connection". The popup's catch block handles it (shows "Error"), but the user has no indication of why — and retrying will likely work.

Minor, but worth noting: apiFetch('/v1/mcp/token', { method: 'POST' }) sends a POST with an empty body. If the server expects a JSON body (even {}), this could 400. The other POST call (submitConversation) always includes a body. Confirm the /v1/mcp/token endpoint accepts an empty-body POST.