ok weird question, please excuse the title I wasn’t sure how to phrase it.
I am using Bitwarden’s ssh agent to hold my SSH keys for git access and commit signing.
I am using VSCodium as my IDE.
If I launch my IDE from the cli with just codium it all works fine.
If I launch my IDE from the KDE start button menu, the SSH agent auth won’t work and I can’t work out why!?!
It won’t launch the prompt in Bitwarden for authorization if I pre-authorize by running the app from the cli, then re-launching from the menu; it still won’t work.
Running git directly in my zsh terminal works fine.
For Bitwarden, I am using the one from the official repo’s. For vscodium, I am using the one from the AUR vscodium-bin as it’s the one with all the MS stuff stripped.
Bitwarden
ssh agent enabled in settings
keys imported
Git
I have a .gitconfig file.
[gpg]
format = ssh
[user]
name = user
email = user@example
signingkey = ssh-ed25519 AAAAC...2a9qcS/+
[commit]
gpgsign = true
[gpg "ssh"]
allowedSignersFile = /home/user/.ssh/allowedSigners
[core]
sshCommand = /usr/bin/ssh
ZSH
I have export SSH_AUTH_SOCK=/home/user/.bitwarden-ssh-agent.sock set in my ~/.zshrc
I have checked the app shortcut in the menu, and it just runs codium as well. So I am unsure why it’s not getting the same settings.
I tried playing around with the launch setting by adding the env var for the socket in front of the codium command and nothing.
Biwarden from Manjaro extra repository has not been updated since Oct 2025
$ pamac info bitwarden
Name : bitwarden
Version : 2025.10.0-1
Description : A secure and free password manager for all of your devices
URL : https://github.com/bitwarden/clients/tree/main/apps/desktop
Licences : GPL-3.0-only
Repository : extra
Packager : Alexander Epaneshnikov <alex19ep@archlinux.org>
Build Date : Fri 31 Oct 2025 08:22:59 GMT
Latest version of bitwarden is available from AUR:
$ pamac info bitwarden-bin
Name : bitwarden-bin
Version : 2026.3.1-1
Description : A secure and free password manager for all of your devices.
URL : https://bitwarden.com
Licences : GPL-3.0-only
Repository : AUR
Groups : --
Depends On : alsa-lib gtk3 libnotify org.freedesktop.secrets libxtst libxss libnss_nis nss
Optional Dependencies : --
Make Dependencies : --
Check Dependencies : --
Provides : bitwarden
Replaces : --
Conflicts With : bitwarden
Maintainer : yochananmarqos
First Submitted : Tue 29 Oct 2024 21:08:11 GMT
Last Modified : Thu 02 Apr 2026 18:48:06 BST
Votes : 15
Out of Date : --
@jofi
I just tested and it doesn’t seem to make a difference. I tried adding options about the auth sock there as well and that didn’t change any thing.
I’m only assuming its Auth sock related as I get a public key error when trying to read from the repo.
@nikgnomic
Thank you, I will have to look into the package and find out why it is so far behind.
But it is working fine when I launch the IDE via the terminal, so I am unsure if it’s version is related.
Edit: I checked all the packages, Bitwarden looks to drop multiple builds a month, so the AUR it way ahead. But Arch has only just recently swapped to 2026.2.1-1 in its stable branch and we have that version in our unstable branch as expected. So we should be ok there.
That works! Thank you so much!! @Molski
My only problem is that it doesn’t persist over reboots.
After a reboot, if I use systemctl --user show-environment I can no longer see it and have to import it again.
Checking the Arch Wiki it looks like I should add a .conf file to ~./.config/environment.d/ with SSH_AUTH_SOCK=/home/user/.bitwarden-ssh-agent.sock
Does that look right?
Edit: Reading the archi wiki further, I might just do the steps under,
2.1.3 Re-using the shell login environment
If you normally set your environment through the shell login mechanisms (i.e. in ~/.profile, ~/.bash_profile, ~/.zprofile, or similar), the shell login environment can be read into a systemd user instance using the systemd.environment-generator(7) logic (as above). Create the following script: /etc/systemd/user-environment-generators/10-profile #!/bin/sh env -i -- $SHELL --login -c env | grep -vE '^(_|SHLVL|PWD|OLDPWD)='
The script invokes your $SHELL as a login shell, and dumps the resulting environment, while removing ephemeral shell variables. This is executed only once, on manager start, and can be reloaded on demand, using systemctl --user daemon-reload.
This seems like it would keep references to the SSH_AUTH_SOCK more centralised so its easy to update if I ever need to.
I would like to understand this. I don’t use Bitwarden but ssh-add and this works regardless of how i run code-oss. If i open the terminal inside code-oss the environment variables are set.
$ echo $SSH_AUTH_SOCK
/run/user/1000/gcr/ssh
@akin2silver What exactly works when running codium from the cli which doesn’t work when launching from the menu?
In another direction, isn’t the menu editor’s environment variable section meant to set, well, the environment variables? Bonus question, when putting the check mark in “Run in terminal” what’s the difference to using the cli? Or rather if the app doesn’t inherit the shell environment why does it work when “launchning from the cli”?
When launching vscodium, if I launch from the terminal by just running codium. The SSH-Agent stuff works with Bitwarden. Allowing me to store my SSH keys in Bitwarden rather than plain text in a file. This is all related to the GUI, not running a terminal in VSCodium.
If I just launch VScodium from the KDE menu, the git functions in the GUI won’t auth correctly and will throw public key errors. I also won’t get prompted in Bitwarden to authorize use of my keys like I do when I use the terminal launched version of VSCodium.
