Good afternoon. We are using bw cli to get login/passwords in powershell scripts. I’ve been using the BitwardenWrapper module with version 2024.3.1 until last Friday, when it didn’t work anymore. I updated to 2025.10.0, and now I am getting prompted to enter the master password after about an hour of the scripts running.
The module saves the session in a file and retrieves that whenever it’s started, using import-module. I have verified that it is reading the file, but I still can’t get items using ‘bw get item –session $env:bw_session’.
The most recent version of BitwardenWrapper is 2024.5.1.1141, which is supposed to be used with CLI version 2024.3.1.
If this combination “doesn’t work”, then there may be a compatibility issue between the old CLI and modern versions of the Bitwarden server.
The appropriate remedy would be for the BitwardenWrapper project to be updated by its owner (which may not be likely, given that there have been no updates for over 1.5 years).
Alternatively, you could self-host a deprecated server version that is compatible with the 2024.3.1 version of the CLI.
When I tried to run it, it told me that the version wasn’t supported and to update to the latest version of the cli. I updated it, and named it the same as the other file. It worked for about 30 minutes, then started prompting for the password again.
This is more of where I’m getting at. Is there a “proper” way to just use bw-cli in powershell, without relying on the module, and not having it prompt me for a password every time?
CLI documentation is available here. Upon logging in, you should receive a session key, which you can set as an environment variable or pass as an option (--session) in the command-line expressions.
According the the documentation, “session keys are valid until invalidated using bw lock or bw logout , however they will not persist if you open a new terminal window.”
@grb Thanks for the links. I am trying to figure out the best solution for my system. I have several scripts that run repeatedly throughout the day. The bitwardenwrapper has worked for us since we started using bitwarden. Even after changing the version that it uses, and it downloading the latest, it works for about 2 hours, then starts prompting for a master password again. In order for me to re-login for another 2 hour session, I have to delete the data.json from the %appdata% directory, logout and login again again.
So, I started looking at using the api login (we use 2fa, so I can’t log in with username and password) at the beginning of each script, then getting a session by running ‘$env:bw_session = bw unlock –passwordenv bw_password’. This successfully sets the bw_session, but it still prompts me for the master password when I try to do a ‘bw list items’, and when I do a ‘bw status’ it tells me that the vault is locked. I even tried this on a brand new pc without the bitwardenwrapper installed, just bw cli.
This is very frustrating. I have about 20 scripts that run every half hour that hit different systems.
This is not normal, and points to some kind of corruption (likely caused by the deprecated BitwardenWrapper utility).
Not sure what you mean. Using the CLI, you can login with some 2FA methods (authenticator TOTP, email OTP, or Yubico OTP).
So you are using the API key method to authenticate? Or are you using the RESTful API?
The status changes to “locked” immediately after you unlocked using bw unlock?
I will try my best to help you with troubleshooting, but I am not an expert on all the ins and outs of the CLI. Thus, it may be a good idea for you to reach out the Bitwarden’s Support Team for additional assistance, if you haven’t already done so.
I created an api key for my user, set the environment variables, then used ‘bw login –apikey’. It does not give me a session id, so then I have to use ‘bw unlock –passwordenv bw_password’ (also set in environment variables), and it gives me session id. I set it to $env:bw_session, but it doesn’t allow me to get anything. And it never says “unlocked” after I do bw unlock, even if I do it manually.
Then why not try logging in using username/password/OTP instead of the API key? See if that makes a difference.
Also, PowerShell variable names are supposed to be case insensitive in Windows, but just in case, try assigning the session key to BW_SESSION instead of bw_session.
I just received an email from support, saying that they’re aware of an issue and are looking at it. Until they fix it, I have to logout, delete the data.json file, login, unlock at the top of the script. This flow looks like it works.
Well, there may be a bug in CLI version 2025.10.0, because bw status seems to always return "status": "locked", whether the vault is unlocked or locked:
But, when bw cli (on linux, at least) is logged in, bw status returns unlocked if BW_SESSION is set correctly, and returns locked if BW_SESSION set incorrectly (or unset).
Always:
kiko@penguin:~ $ export BW_SESSION="***the_correct_session_key***"
kiko@penguin:~ $ bw status
{"serverUrl":"https://vault.bitwarden.eu","lastSync":"2025-11-07T19:22:53.568Z","userEmail":"my@email.com","userId":"********-****-****-****-************","status":"unlocked"}
kiko@penguin:~ $ unset BW_SESSION
kiko@penguin:~ $ bw status
{"serverUrl":"https://vault.bitwarden.eu","lastSync":"2025-11-07T19:22:53.568Z","userEmail":"my@email.com","userId":"********-****-****-****-************","status":"locked"}
kiko@penguin:~ $ export BW_SESSION="***the_correct_session_key***"
kiko@penguin:~ $ bw status
{"serverUrl":"https://vault.bitwarden.eu","lastSync":"2025-11-07T19:22:53.568Z","userEmail":"my@email.com","userId":"********-****-****-****-************","status":"unlocked"}
kiko@penguin:~ $ export BW_SESSION="garbage"
kiko@penguin:~ $ bw status
{"serverUrl":"https://vault.bitwarden.eu","lastSync":"2025-11-07T19:22:53.568Z","userEmail":"my@email.com","userId":"********-****-****-****-************","status":"locked"}
So, I had problems with this, because if I had two scripts running at the same time, and one deleted the json.data file, the other bombed out. So, now I’m setting the application dir to c:\temp\bw\GUID, logging in, unlocking, getting info, then removing the folder. I get an email every time too.. thank goodness for outlook rules.