Bitwarden on macOS 15.3 occasionally doesn't realease Secure Keyboard Input, preventing global hotkeys from triggering for other apps.

[Sean1708]

Steps To Reproduce

I've not yet found a way to reliably force this bug to occur (i.e. without having to wait), but the following steps do eventually trigger the bug for me.

1. Set "Start to menu bar" and open Bitwarden without logging in (alternatively set "Close to menu bar" and close the window without logging in). This bug might also occur if you leave the window open without logging in, but I haven't seen that happen myself yet.
2. Wait for some amount of time (it's hard to say exactly how much time, but I think somewhere around about 30 minutes).
3. Try triggering a global hotkey associated with a different app (e.g. the hotkey window of iterm2).

Expected Result

The hotkey triggers successfully.

Actual Result

The hotkey does not trigger and a notification is displayed saying that another app has Secure Keyboard Input enabled. Quitting Bitwarden fixes the issue.

Screenshots or Videos

No response

Additional Context

No response

Operating System

macOS

Operating System Version

Sequoia 15.3

Installation method

Mac App Store

Build Version

Version 2025.1.3 SDK 'main (28c7e29)' Shell 33.2.1 Renderer 130.0.6723.137 Node 20.18.1 Architecture arm64

Issue Tracking Info

• [x] I understand that work is tracked outside of GitHub. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[bitwarden-bot]

Thank you for reporting this issue! We've added this to our internal tracking system. ID: PM-17952

[cbw23]

Hi there,

I am unable to reproduce this issue, it has been escalated for further investigation. If you have more information that can help us, please add it below.

Thanks!

[dessmith]

This is occurring for me on MacOS 15.3.1 (24D70), Bitwarden Desktop Version 2025.2.0 (37899), when running Bitwarden to start with login (the icon sits on the top bar). I mostly use my MacBook Pro in clamshell mode.

This prevents me from opening iTerm2 using my shortcut `Option + ``. You can see a user complain about Bitwarden causing this in this forum post in the BetterTouchTool forum (app that can create shortcuts among other things), along with a discussion on other apps not releasing Secure Keyboard Input https://community.folivora.ai/t/secure-input-preventing-btt-from-functioning/26649/9

To "resolve" this I have to quit and repoen Bitwarden.

[Sean1708]

I've not really got any extra information on it, but it hasn't happened for a week or two so if there's been a change to this functionality recently then maybe it's been fixed? Certainly I noticed that previously iTerm2 would always show the Secure Keyboard Input icon until I quit Bitwarden but now it only shows the icon when Bitwarden is focussed.

It seems fixed for me and I'm happy for this issue to be closed, but if other people are still experiencing it on the latest version then maybe it should be left open for now.

[bin101]

Unfortunately, this issue still occurs regularly on my M2 air with 15.3.1

edit: I reinstalled the desktop client from the store and since then I didn't noticed any hotkey lockups. I will let you know if this changes.

[rpoovey]

+1 on this issue. If the vault locks on logout it holds up secure keyboard entry and prevents applications like skhd from functioning. Work around for me is to disable all vault locks and timeout, even on device lock.

[pollymow]

I can confirm that this is still an issue for Version 2025.3.0 (39877). When the vault is locked according to the setting, all the menubar related settings seem to use an invisible background window with the cursor set into a secure input field. This is extremely bad, because it will prevent a great many of applications monitoring the keyboard for triggering macros, inserting templated text etc. etc. from working at all.

The KeyboardMaestro editor in this case posts an error in its main window giving the following explanation: Secure Input is enabled which means the system thinks you are currently in a password field and will not allow applications to monitor the keyboard. This will stop Typed String triggers from working, as well as stop Keyboard Maestro from sensing your keystrokes while setting hot keys. You will need to find the offending application (probably Bitwarden) and quit it.

See also the explanation at the following URLs: Secure Input Problem and TextExpander and Secure Input

Previous text:

User rpoovey's workaround to disable all vault locks is necessary but extremely undesirable from a security standpoint. The vault should stay locked whenever possible.

Later edit: It is, as it turns out, NOT necessary to disable all vault locks: it is enough to maximise Bitwarden's main window, click somewhere outside the secure input field and close/minimise the window again (i. e. without unlocking the vault).

So for the programmers there should be a very easy fix: if you intend to go on using a hidden window, simply make sure that the cursor is NOT set in the secure input field, if possible. As a convenience the cursor could be set into the secure input field only at the very moment when the user unhides the hidden window by GUI interaction.

Hope this gets fixed soon since it is extremely inconvenient and annoying

[slifty]

Wanted to jump on to say this is happening to me as well, across multiple devices. It started after upgrading to Sequoiua (I'm currently 15.4.1 and it's happening there too).

It appears to happen when vaults auto-lock and the Bitwarden client is in the background.

[pollymow]

Apart from that, a Bitwarden blocking secure input as described, seems to make it use a lot more CPU than otherwise.

[slifty]

Apart from that, a Bitwarden blocking secure input as described, seems to make it use a lot more CPU than otherwise.

I'm gonna have to keep an eye out for this. Have you noticed this as part of the keyboard input issue or just generally? If general, it might be worth opening a separate issue to capture the symptoms in more detail which would increase the odds of it being investigated / addressed.

[pollymow]

Apart from that, a Bitwarden blocking secure input as described, seems to make it use a lot more CPU than otherwise.

I'm gonna have to keep an eye out for this. Have you noticed this as part of the keyboard input issue or just generally? If general, it might be worth opening a separate issue to capture the symptoms in more detail which would increase the odds of it being investigated / addressed.

I started a Sonoma system with some apps starting at login, among them Bitwarden, on my MacBook Pro 2020. I left it open, where it went to sleep after 20 Minutes or so. For some completely unrelated reason, when I went back to the machine, I wanted to find out the cumulative major CPU and Power consumers on that machine (expecting data from before the last resboot, which was not the case). I was astonished to see that Bitwarden, dangling with a blocked secure text input field and its blinking cursor (in the background), was the no. 1 power consumer during the 20 minutes where the MacBook was ideling before going to sleep. Before I found Bitwarden to have a very minimal CPU and therefore power footprint.

Anyhow, it should be a rather easy fix, and it should be done, ASAP.

[ericgbradshaw]

I’m also facing this issue. I’ve also noticed the same behavior that seems to trigger it. It happens almost daily for me if I leave the Bitwarden MacOS desktop client open.

I leave Bitwarden open/logged in, it auto-locks, and then when coming back to use the computer a while later after the screen has been off a while, input with logitech keyboard/mouse controls doesn't not function properly and inputs are not recognized at all for certain keyboard or mouse buttons. As soon as I close Bitwarden desktop client, the issue immediately goes away and Logitech button inputs functions as normal again.

This issue is really frustrating and kind of sucks to have to keep closing the software after every password fill to avoid the problem.

I use the latest version of MacOS and DuckDuckGo as my primary browser with Bitwarden integration as my password manager.

Is a fix for this in the works?

[slifty]

I also still face this very regularly / any time I forget to close the bitwarden client after use.

I contacted support directly about this in April ago and received the following response on April 28th:

Thank you for reaching out to Bitwarden Support!

Our engineers are currently addressing this issue, and I will make sure to pass your feedback along to them. We encourage you to leave any further input directly on our GitHub page, where our engineers can see it firsthand. We anticipate that this will be resolved in a future release.

Which I took / take to be good news (though if another month passes with no resolution I'll feel less optimistic 😅)

[ellie-ripley]

This is an ongoing issue for me as well. I haven't figured out how to reliably trigger the issue (other than just waiting a while), but the only thing that seems to fix it is closing Bitwarden. On Sequoia 15.5, with Bitwarden managed through the App Store, currently on version 2025.5.1 (43022).

[slifty]

Well, the month passed with no resolution so I'm back to being less optimistic! I'll send another support ticket but meanwhile at least wanted to bump the thread lest a bot declare it stale.

This is a daily annoyance.