Hey folks! 👋 Has anyone else been having a constant issue with the WellSaid Labs Chrome extension logging you out after every browser restart, or even sometimes just randomly during a session? It's getting a bit frustrating to have to re-authenticate so often, especially when I'm in the middle of a workflow.
I've tried the usual steps:
* Uninstalling and reinstalling the extension.
* Clearing browser cache and cookies for the site.
* Ensuring I'm logged into the main WellSaid website in the same browser profile.
* Checking that the extension is updated to the latest version.
The problem still comes back. I'm starting to wonder if it's a cookie/local storage permission issue. I checked the extension's permissions in `chrome://extensions/`, and it has "storage" access. Could there be a conflict with another extension or a specific browser setting?
Here's a little test I ran in the browser console (on the WellSaid app page) to see if the session data is persisting, which might give us a clue:
```javascript
// Check if we can see stored tokens (run on the WellSaid Labs web app domain)
console.log('Local Storage length:', localStorage.length);
console.log('Session Storage length:', sessionStorage.length);
```
If others are seeing this, maybe we can crowdsource a solution. What browser and OS version are you using? For me, it's Chrome 128 on macOS Sonoma. Sharing your setup might help us spot a pattern.
Happy coding!
Clean code, happy life
Yep, seen it before. It's almost always a third-party cookie blocker or your browser's privacy settings nuking local storage between sessions. Check `chrome://settings/content/all` for the WellSaid domain and make sure it's not set to "clear on exit."
Also, your console test is pointless if you run it while you're logged in. The extension runs in its own isolated context, separate from the web page. You need to check the extension's background page console via the extension's inspect view. That's where it's actually storing (or failing to store) its auth token.
If it ain't broke, don't 'upgrade' it.
Yeah, that console test on the web page might not show the whole picture. The extension uses its own storage, separate from the site. I'm curious, have you checked if you're using any other extensions that clean up local data automatically, like a privacy tool? I had a similar thing happen once with a different extension.
The storage permission is necessary, but it might not be sufficient if the browser is set to aggressively clear site data on exit. The other replies about checking `chrome://settings/content/all` for the domain are the right next step.
Since you've already done the basic reinstall steps, I'd focus on the browser's privacy settings and any other installed extensions. Some security or "cleaner" tools can wipe extension storage without you realizing it. Try disabling other extensions one by one in a test profile to see if the logout behavior stops.
The "cleaner" extension angle is a solid one, and something I've seen in production incident reviews. We had a case where a third-party cookie/tracker blocking extension was aggressively pruning `chrome.storage.local` for *all* extensions, not just its intended targets, because it was using a blunt API.
Testing in an isolated browser profile is the correct, methodical approach. However, I'd also recommend pulling the extension's own logs during the failure mode to confirm the hypothesis. If you open the extension's background page inspector (`chrome://extensions/`, enable Developer mode, click "inspect views background page") and watch the console right before a browser restart, you might see explicit errors from `chrome.storage.local.set` failing, which points to a permissions or quota issue rather than a passive cleanup.
Latency is a liability
That's a great callout about the extension's background page logs. Seeing a storage error there would instantly point to an active blocker, while no error would point more towards a passive cleanup after the fact.
I've also seen aggressive privacy settings or "automatic cleanup" features in the browser itself do this, not just extensions. Chrome's own "Clear cookies and site data when you quit Chrome" under Privacy and Security can be a sneaky culprit.
Exactly, the distinction between active blocking errors and passive cleanup is crucial for diagnosis. If you don't see storage API errors in the background page before restart, then the culprit is almost certainly the passive cleanup setting you mentioned.
To validate, the OP should check `chrome://settings/clearBrowserData` on exit. If "Cookies and other site data" is enabled, that will also clear extension storage for *all* extensions, not just site-specific data. This is a common oversight in Chrome's privacy controls that treats extension state as ephemeral by default.
A more insidious version I've seen is enterprise or educational Chrome policies that enforce this setting globally, leaving the user with no visible toggle to change it.
Show me the numbers, not the roadmap.
Right, the enterprise policy angle is a real gotcha. I've had to help a few coworkers with this exact scenario - their managed Chrome instance was silently enforcing that cleanup on exit. If you're on a work or school machine, checking chrome://policy/ can reveal if something's being forced that you can't override locally.
In those cases, the only real workaround was either getting an exception from IT or, less ideally, using a separate personal Chrome profile for extensions that need persistence. Not perfect, but it's a common limitation in locked-down environments.
K8s enthusiast
Oh, that's such a good point about chrome://policy/. I helped a colleague last month where that was the exact problem, and the policy was called something super vague like "DefaultCookiesSetting" that you'd never connect to extension storage.
It's a tough spot for users because the setting isn't visible in the normal UI. The separate personal profile workaround feels clunky, but it's honestly the path of least resistance most of the time. 😅 It makes you wonder if extension developers should add a little warning in their onboarding if they detect that policy.
That policy detection idea is clever! It'd be great UX, but the tricky part is actually querying the policy list programmatically. I don't think the Chrome extension APIs expose `chrome://policy/` data directly for privacy reasons, so a dev would have to get creative.
You could maybe check for the *symptom* - like attempting a storage write on install and seeing if it persists after a simulated restart - but that's a bit of a hack. Might be better as an FAQ entry.
edge cases matter
Disabling other extensions one by one is tedious, but it's free. Good call.
Just be aware that some "cleaner" tools don't play nice even when disabled - they can leave behind settings or schedules. Might need a full uninstall to rule them out.
always ask for a multi-year discount
That console test is a smart way to check persistence on the web app side. But keep in mind the extension likely stores its auth in a different place - probably chrome.storage.local - not your browser's localStorage for the site. So that test might not show the root cause.
If you want a more direct check, open the extension's background page console like user1545 mentioned. Watch it right before you close the browser. If you see no errors, then the data is being cleared *after* the extension saves it, which points straight to those cleanup settings or policies others flagged.
I'd skip the extension conflict test for now and go straight to chrome://settings/clearBrowserData to see what's checked on exit. That's usually the culprit.
✌️
Getting an exception from IT is often a fantasy. That "policy" exists because some security checklist says it must, and no one has the authority or will to carve out an exception for a single browser extension.
Even the separate personal profile workaround is getting harder. A lot of managed devices now block signing into any non-corporate Google account, or they force sync to be disabled. You're left with a useless, sandboxed local profile that can't even save your bookmarks.
It's a designed dead-end. The policy isn't there for your productivity, it's there to reduce the admin's support burden, full stop.
Trust but verify.
That console test is useless. The extension doesn't use localStorage for auth.
It uses chrome.storage.local. If your chrome://settings/clearBrowserData has "Cookies and other site data" checked on exit, it wipes that too. That's the first thing to check.
Prove it with a benchmark.
You're barking up the wrong tree with that console test. The extension's auth token lives in `chrome.storage.local`, not the web page's `localStorage`. Your test proves nothing.
Your "cookie/local storage permission" hunch is also wrong. The "storage" permission is for the extension's own storage, which it has. The problem is external deletion.
Check `chrome://settings/clearBrowserData`. Look at the "On exit" tab. If "Cookies and other site data" is enabled, it nukes extension storage on every close. That's your most likely culprit.
Data over opinions