Keystroke of "^" Character not recognized in macOS Bitwarden Desktop App

[Stungler]

Steps To Reproduce

1. Go to 'Bitwarden Master-PW Login Screen (Also works on Edit Entry Password Field)
2. Type in Password containing the character "^"
3. Reveal password to see the "^" characters didn't register.

This is especially annoying since you don't see that it doesn't register, since the password isn't visible. I'm on a German QWERTZ Keyboard if that may be relevant. I can reproduce this just in the macOS Desktop App. All other variants i tried work fine (Browser-Plugin, Windows-App, Android-App, Bitwarden WebApp on the Website)

UPDATE 2025/12/29: The Bug also occurs when parsing other so called "dead keys" like "´" and "`"

Expected Result

Keystroke of char "^" Appears in the password entry field

Actual Result

Keystroke of "^" char doesn't appear in the password field, you need to make it visible and manually place your cursor there and type it again, then it works.

Screenshots or Videos

No response

Additional Context

No response

Operating System

macOS

Operating System Version

macOS Tahoe 26.1.0

Installation method

Direct Download (from bitwarden.com)

Build Version

2025.11.0

Issue Tracking Info

• 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-30261
Link (for internal use): https://bitwarden.atlassian.net/browse/PM-30261

[pamperer562580892423]

Another user here.

Indeed, I can reproduce that (Windows 11 - also German keyboard, BTW) - but not in all circumstances. In the few tests I did with the "unlock with master password" field, it only happens for me when ^ is the very first character.

And as you described, when made visible once, it works then afterwards even when the characters are hidden again. (but only when the characters are changed -- when they're unchanged and I toggle, the ^ still isn't visible)

I also have the impression, that that this bug also only shows itself if it's one of the first actions after app start. E.g. after app start I just switched accounts or rather wanted to add a new account to make a GIF of the bug, and therefore I entered a random email address, but then in the master password field, the bug didn't show.

So, for reproduction, I would recommend:

• immediately after app start (don't input anything else)
• the ^ must be the first character of the "master password" input

(but maybe there are more conditions for that bug to appear...)

PS: I forgot to add: I tested this on desktop app version 2025.12.0. (Windows 11 Home 25H2, Build 26200.7462)

[Stungler]

Another user here.

Indeed, I can reproduce that (Windows 11 - also German keyboard, BTW) - but not in all circumstances. In the few tests I did with the "unlock with master password" field, it only happens for me when ^ is the very first character.

I think this is not true for me, my master pw contains several "^" none of them register. And none of them are the first char of the pw, they are between numbers though, maybe that makes a difference. I can reproduce it 100% on my end.

[pamperer562580892423]

I think this is not true for me, my master pw contains several "^" none of them register. And none of them are the first char of the pw, they are between numbers though, maybe that makes a difference. I can reproduce it 100% on my end.

That could mean there is a difference on the platforms (MacOS, Windows, ...). Or maybe also due to the different desktop app versions (you reported 2025.11.0, and I tested it on 2025.12.0) - would be interesting to know if it changes for you with the current 2025.12.0 version on MacOS.

[bwbug]

FWIW, I am unable to reproduce using a US keyboard (on a Windows 11 system, portable Desktop app version 2025.12.0). However, as I use the account switcher and an account that has the Timeout set to "Never", I wasn't sure how to avoid inputting anything else before the first ^ on app restart. My procedure was:

1. Enable "Unlock with PIN", make the PIN ^6^6, and disable "Lock with master password on restart".
2. Lock the account.
3. Restart the Desktop app.
4. Type the PIN and then toggle the visibility using the 👁️ icon.
5. Click Unlock.
6. Click on a vault item that is protected by "Master password re-prompt".
7. At the "Master password confirmation" prompt, type ^ and then toggle the visibility using the 👁️ icon (Note: the account master password does not start with an ^ character; this was typed just for testing purposes).

The results were that I can see the ^ after toggling visibility in Steps 4 & 7.

[pamperer562580892423]

I now can add a short video.

What you see: I mainly tried to type ^123 (BTW copy & paste doesn't produce that bug for me, only typing!) - and added some ^ characters after that. In the first test, the ^ is invisible (or actually: a space character!), and in the second round, though I do the same as before, the character becomes visible.

(the German keyboard produces the ^ character with pressing the corresponding key and then another key, like the "space bar" - so maybe indeed the space bar input gets processed and inserted here, instead of the correct character ^ ?)

bw-bug-special-character-input-desktop-app.mp4

PS: And as I wrote before, as switching the account now "live" doesn't show the bug - and I was too lazy to log out my own main account - so, this (master password unlock field) was the only condition I tested it with... also, because it already reproduced it (at least in part).

PPS: Ah, and it indeed only affects the location of the first character (again, at least for me, on Windows 11, and with desktop app 2025.12.0):

bw-bug-special-character-input-desktop-app-2.mp4

(in this second video, my input was ^123^^^, but visible was only 123^^^)

[rmcdowell-bitwarden]

Hi there,

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

Thanks!

[pamperer562580892423]

@rmcdowell-bitwarden I had an idea: the virtual keyboard could make the input visible. And it worked - so I made an "integrated remake" of my first two videos, now with a virtual keyboard (if you turn on the sound, you can even hear the "clicks").

Here (in part again) the conditions for how I can reproduce it:

• desktop app version 2025.12.0
• on Windows 11 Home 25H2, Build 26200.7462
• so far, I only saw it after a fresh start of the desktop app (i.e. the first thing I try after start of the app was - like in the video - to provoke that bug)
• and for me, I only see that bug when the ^ is the first character I enter in the field (if I add ^ characters later, they are visible when I toggle visibility)
• and as I still test out the "new biometrics", I use Windows Hello to unlock at the moment - and therefore I also have "Require master password or PIN on app restart" unchecked in the desktop app at the moment (I don't know if that "state" of the app plays a role here or not)
• and then, as you can see in the video, when I just started the desktop app and (first thing) go to "Unlock with master password" (in my case), then I can provoke that bug
• (in the video, you can again see two "rounds": in the first test, the first ^ is not visible / is a space character - in the second round, after deletion of the previous input in the field, the first ^ is visible, while it's the exact same input in both "rounds")
• and the bug only shows when the input is not made visible via the "eye" toggle - only when you toggle visibility after typing it in, you can see the wrong first character
• and last but not least, that bug only shows itself via actual typing -- copy & paste a password doesn't provoke that bug

bw-bug-special-character-input-desktop-app-3-virtual-keyboard.mp4

[Stungler]

Screen.Recording.2025-12-29.at.11.03.39.mov

Here is a reproduction of the issue appearing between characters. If i enable visibility (via the eye) it works just fine. The issue just occurs when the pw is censored.

[pamperer562580892423]

@Stungler That video... - is that still desktop app 2025.11.0?

[Stungler]

@Stungler That video... - is that still desktop app 2025.11.0?

No, i updated. I added the Version to the comment

[pamperer562580892423]

@Stungler I only now saw your video in detail - and it seems we don't even experience the same issue (or maybe we both experience the same issue differently?! - because they do seem related and have to do with ^ as typed input).

Short summary:

• in my case, the first ^ seems to get replaced by a space character
• in your case it seems, any ^ input doesn't get processed at all

Do you agree?

PS: I now wonder, if there could be other special characters causing such an anomaly as well. 🤔