Firefox Bitwarden extension: timeout set to 'never', but logs out "frequently"

rtoledo2002 · June 7, 2025, 9:12pm

Greetings, I Know some will say it’s not safe. but I want it in my home computer .

every day now I have to log into bitwarden in firefox .

Was this taken away ? my Android still has it set to never

thank you for tips

Nail1684 · June 7, 2025, 9:17pm

Because it isn’t.

I’m a bit confused now.

Does your Firefox BW extension doesn’t have the setting “never”? (sounds like it when you write “Was this taken away?”)
Or do you have the setting, but when you set it to “never” it (frequently) locks/logs you out?
Or do you have the setting, but the setting get’s lost altogether and sets itself to the default setting? (I think the default is “On browser restart” )

(when you write “no longer stays on NEVER” in the title, that sounds more like 2. or 3. than 1.)

Anyway, did you already try to log out, deinstall(/remove) the extension and reinstall it? (do that only, if you are able to login to Bitwarden again - master password, 2FA etc.)

Nail1684 · June 7, 2025, 9:42pm

PS: I just checked - I still have “Vault timeout – Never” in the BW Firefox extension 2025.5.0:

rtoledo2002 · June 7, 2025, 9:46pm

it’s #2 and unlock options do not have ck marks

Nail1684 · June 7, 2025, 10:36pm

Okay. (PS: I updated the title, to better reflect what is going on with your extension)

So you intentionally don’t use locking/unlocking? And your vault timeout action is “log out”?

Did you already do this in the meantime:

?

You could also think of setting up a locking/unlocking option (with PIN or biometrics) and set the vault timeout action to “Lock”. Then you wouldn’t have to fully login again, but only unlock the extension.

rtoledo2002 · June 8, 2025, 5:53pm

I went ahead and did what you suggested. put a pin , so if it does a pin is easier

thank you

rtoledo2002 · December 21, 2025, 10:32pm

OK , I’m back . just to clarify , this thread should be about the firefox plugin > Win 26200.7642 build

I’m on version 2025.12.0. > As for safety , the laptop is set to lock up fast, I only use a pin on win 11 2025h1 build 10.0.26200.7642 .

I continue to have it ask for the main password ever couple of days.

I have tried clicking on the pin and setting a pin , it never asks for the pin , just the main password.

timeout is set to never, timeout action have tried both ,

not worried that Trumps Gestapo will want my passwords .

I worry more about me typing that LONG password of mine , (I use Bitdefender on all computers and cell phones )and the possibility of a key logger , but then my most important accounts have 3 yubikeys in them , except for F’ing banks like Chase , Usbank , and Sofi that do not accept them , just plain sms to my phone .

There are other things about Bitwarden that I just don’t get (for another topic I guess) , like I’m the account owner , I have the family plan , I went through the steps to set up my wife and my son as “ co-owners “ or what ever the term is, but when I need to grab a password for a web site that my wife belongs to , trying to help her (she has NEVER understood or remembers )on a web site. I end up getting up and moving her away from her computer to fix whatever this month’s new redesign has been done to one of 30 bills she needs to pay, including those low effort / IQ lacking web site that do not even allow Bitwarden to populate . (I can use a link in here to such a thread or how to )

So can we get this issue (locking up issue) fixed PLEASE.

Happy Holidays to US ALL , God knows we need it

Best Regards

Roman Toledo

Nail1684 · December 21, 2025, 11:07pm

Well, kind of an update: this was also discussed here last month – and there is a related PR on GitHub, that you could also follow (“subscribe” to get notifications):

github.com/bitwarden/clients

[BEEEP] Refresh access token on 401 API response

main ← platform/handle-401-refresh-token

opened 09:01PM - 15 Nov 25 UTC

trmartin4

+956 -69

## 🎟️ Tracking https://bitwarden.atlassian.net/browse/PM-28303 fixes https…://github.com/bitwarden/clients/issues/10718 ## 📔 Objective Attempt to refresh the access token if we receive a `401` response from an API request. This matches the behavior on the mobile applications, and accounts for scenarios in which we've seen requests being delayed client-side (seemingly related to host sleep/hibernate states), only to proceed after the machine is active, at which point the now expired access token fails. This change is meant to specifically address the case where: 1. We make an authenticated API request with an access token that is valid (not expired) at the time that our code calls `fetch()`. 2. For some reason, the request is not sent to the server until _after_ the access token has expired. 3. The Bitwarden API rejects the request with a `401` response because the token is not valid. Specifically in this scenario, if we run the request building logic again, **the access token will now be detected as expired** and a `refresh_token` request will be issued to Identity. This refreshed access token can then be used to successfully send the request. Besides renames and using `HttpStatusCode`s instead of magic strings for HTTP response statuses, the following substantial changes were made: 1. Added check for a `401` response on an authenticated request, and call `buildRequest()` again to refresh the token. 2. Changed the logout reasons to `SessionExpired` for an invalid refresh token (meaning that the refresh token (aka a "session" is no longer valid) and `InvalidAccessToken` for an API request that receives a `401` or `403` response. PR https://github.com/bitwarden/clients/pull/17608 builds on this by adding a log message on every logout with a reason. 3. Alphabetized the `LogoutReason` type and removed the `invalidGrant` reason, since it was no longer in use. 4. Separated out the response error handling into 2 separate methods for clarity. One handles responses from API requests, and one handles errors from requests to the token endpoint. Why don't we need to check for `401` or `403` on the token request failures? Because we're not calling an authenticated endpoint here, we're calling the token request endpoint, and that endpoint will respond with an [invalid grant](https://github.com/DuendeSoftware/products/blob/508e82a1f2e06ef9ff67d0453b387e8ae71692f3/identity-server/src/IdentityServer/Services/Default/DefaultRefreshTokenService.cs#L79-L80). ⚠️ This does **not** handle the following scenarios: 1. A `401` response is received because the wrong user's access token is sent on a request. 4. A `401` response is received due to network configuration issues. In these case, the token isn't expired, and we'll send up the same (wrong) token again. At that point, we'll get a `401` again and log the user out as we did before. We'll have an extra request in this case, but it will fail both times. ## 📸 Screenshots This demo demonstrates what happens in the scenario that this change covers, by doing the following: 1. Modifying the access token lifetime to be 10 seconds 2. Setting a breakpoint after the access token was acquired (when building the request) and **before** the ``fetch()` is executed. 3. Waiting at that breakpoint for more than 10 seconds. At this point, the token has expired. 4. Sending the request with the expired token. 5. Observing that the response is `401 - Unauthorized` 6. Letting the code execute to see that a subsequent refresh occurs, and the request then succeeds. https://github.com/user-attachments/assets/a5250c87-29f0-4056-b63e-65001aebe675 ## ⏰ Reminders before review - Contributor guidelines followed - All formatters and local linters executed and passed - Written new unit and / or integration tests where applicable - Protected functional changes with optionality (feature flags) - Used internationalization (i18n) for all UI strings - CI builds passed - Communicated to DevOps any deployment requirements - Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team ## 🦮 Reviewer guidelines - 👍 (`:+1:`) or similar for great changes - 📝 (`:memo:`) or ℹ️ (`:information_source:`) for notes or general info - ❓ (`:question:`) for questions - 🤔 (`:thinking:`) or 💭 (`:thought_balloon:`) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion - 🎨 (`:art:`) for suggestions / improvements - ❌ (`:x:`) or ⚠️ (`:warning:`) for more significant problems or concerns needing attention - 🌱 (`:seedling:`) or ♻️ (`:recycle:`) for future improvements or indications of technical debt - ⛏ (`:pick:`) for minor or nitpick changes

I think you meant Bitwarden?

Yep. Please. (also because I’m not sure what exactly the issue is in that paragraph…)

Same to you!

rtoledo2002 · December 21, 2025, 11:32pm

I use both Bitwarden and Bitdefender on ALL computers and cell phones, onlky reason I mentioned Bitdefender was for info on my safety precautions inside the OS. I will look right now at the 2 other things you mentioned. Thank You

Nail1684 · December 21, 2025, 11:34pm

Ah, thanks for the clarification!

rtoledo2002 · December 21, 2025, 11:49pm

I looked at the 2 topics and they are high in the stratosphere above me. I have no idea what the github one does or how I would use it. at 67 years old and poor short term mem, I need a script that would do whatever it is that it’ s supposed to do. I love firefox just as a revel minded person , I only use chrome to post comments on important videos I’m following or need feedback on.

My wife uses Brave only , she loves it and I try the least amount of new things for her. I love Brave on Android to get around Youtube’s bull .

sop just hoping this might get fixed , but it’s not going to move me to other browsers unless there is no other option.

Nail1684 · December 21, 2025, 11:59pm

I think it is enough for us to know this: that GitHub PR (Pull Request) could be a fix for your issue – and when it get’s “merged” on GitHub, it will be in a following release. And after that, we’ll see if it really fixes the issue…

Nail1684 · January 13, 2026, 10:10pm

Update: this relevant PR…

github.com/bitwarden/clients

[BEEEP] Refresh access token on 401 API response

main ← platform/handle-401-refresh-token

opened 09:01PM - 15 Nov 25 UTC

trmartin4

+956 -69

## 🎟️ Tracking https://bitwarden.atlassian.net/browse/PM-28303 fixes https…://github.com/bitwarden/clients/issues/10718 ## 📔 Objective Attempt to refresh the access token if we receive a `401` response from an API request. This matches the behavior on the mobile applications, and accounts for scenarios in which we've seen requests being delayed client-side (seemingly related to host sleep/hibernate states), only to proceed after the machine is active, at which point the now expired access token fails. This change is meant to specifically address the case where: 1. We make an authenticated API request with an access token that is valid (not expired) at the time that our code calls `fetch()`. 2. For some reason, the request is not sent to the server until _after_ the access token has expired. 3. The Bitwarden API rejects the request with a `401` response because the token is not valid. Specifically in this scenario, if we run the request building logic again, **the access token will now be detected as expired** and a `refresh_token` request will be issued to Identity. This refreshed access token can then be used to successfully send the request. Besides renames and using `HttpStatusCode`s instead of magic strings for HTTP response statuses, the following substantial changes were made: 1. Added check for a `401` response on an authenticated request, and call `buildRequest()` again to refresh the token. 2. Changed the logout reasons to `SessionExpired` for an invalid refresh token (meaning that the refresh token (aka a "session" is no longer valid) and `InvalidAccessToken` for an API request that receives a `401` or `403` response. PR https://github.com/bitwarden/clients/pull/17608 builds on this by adding a log message on every logout with a reason. 3. Alphabetized the `LogoutReason` type and removed the `invalidGrant` reason, since it was no longer in use. 4. Separated out the response error handling into 2 separate methods for clarity. One handles responses from API requests, and one handles errors from requests to the token endpoint. Why don't we need to check for `401` or `403` on the token request failures? Because we're not calling an authenticated endpoint here, we're calling the token request endpoint, and that endpoint will respond with an [invalid grant](https://github.com/DuendeSoftware/products/blob/508e82a1f2e06ef9ff67d0453b387e8ae71692f3/identity-server/src/IdentityServer/Services/Default/DefaultRefreshTokenService.cs#L79-L80). ⚠️ This does **not** handle the following scenarios: 1. A `401` response is received because the wrong user's access token is sent on a request. 4. A `401` response is received due to network configuration issues. In these case, the token isn't expired, and we'll send up the same (wrong) token again. At that point, we'll get a `401` again and log the user out as we did before. We'll have an extra request in this case, but it will fail both times. ## 📸 Screenshots This demo demonstrates what happens in the scenario that this change covers, by doing the following: 1. Modifying the access token lifetime to be 10 seconds 2. Setting a breakpoint after the access token was acquired (when building the request) and **before** the ``fetch()` is executed. 3. Waiting at that breakpoint for more than 10 seconds. At this point, the token has expired. 4. Sending the request with the expired token. 5. Observing that the response is `401 - Unauthorized` 6. Letting the code execute to see that a subsequent refresh occurs, and the request then succeeds. https://github.com/user-attachments/assets/a5250c87-29f0-4056-b63e-65001aebe675 ## ⏰ Reminders before review - Contributor guidelines followed - All formatters and local linters executed and passed - Written new unit and / or integration tests where applicable - Protected functional changes with optionality (feature flags) - Used internationalization (i18n) for all UI strings - CI builds passed - Communicated to DevOps any deployment requirements - Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team ## 🦮 Reviewer guidelines - 👍 (`:+1:`) or similar for great changes - 📝 (`:memo:`) or ℹ️ (`:information_source:`) for notes or general info - ❓ (`:question:`) for questions - 🤔 (`:thinking:`) or 💭 (`:thought_balloon:`) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion - 🎨 (`:art:`) for suggestions / improvements - ❌ (`:x:`) or ⚠️ (`:warning:`) for more significant problems or concerns needing attention - 🌱 (`:seedling:`) or ♻️ (`:recycle:`) for future improvements or indications of technical debt - ⛏ (`:pick:`) for minor or nitpick changes

… was merged last week. I think it’s not yet included in the current 2025.12.x releases, but it should improve things with one of the next releases.