The ProblemYou’re trying to sync your GitHub account with VS Code on Linux, but instead of a successful login, a stubborn notification pops up: "Writing login information to the keychain failed." If you check your logs, you'll see a specific complaint about org.freedesktop.secrets. This usually happens because VS Code can't find a secure place to tuck away your authentication tokens.
Why This HappensVS Code relies on the secret-storage API to keep your GitHub tokens under lock and key. On Linux, this API looks for a system-level service that follows the Freedesktop Secret Service specification. This is typically GNOME Keyring or KWallet.
The error triggers when VS Code sends a request over DBus but gets no answer. This is a frequent issue for developers using minimal setups like i3, Sway, or Openbox, where a keyring daemon isn't started by default. It also plagues headless servers and WSL2 environments that lack a native Linux graphical interface.
Solution 1: Install and Initialize GNOME KeyringThe most robust fix is to install the GNOME Keyring service. Even if you aren't running the GNOME desktop environment, this service provides the exact org.freedesktop.secrets interface VS Code is hunting for.
1. Grab the PackagesOpen your terminal and install the necessary libraries based on your distribution:
Ubuntu, Debian, or Linux Mint:
sudo apt update
sudo apt install gnome-keyring libsecret-1-0
Arch Linux:
sudo pacman -S gnome-keyring libsecret
Fedora:
sudo dnf install gnome-keyring libsecret
2. Start the Daemon AutomaticallyIf you use a window manager like i3 or bspwm, the keyring won't start on its own. You need to trigger it during login. Add this snippet to your .xinitrc or your window manager's startup config:
eval $(/usr/bin/gnome-keyring-daemon --start --components=secrets)
export SSH_AUTH_SOCK
Solution 2: Adjust VS Code’s Internal Storage SettingSometimes you can't—or don't want to—install a system-wide keyring. In those cases, you can tell VS Code to handle secrets differently. This is a quick fix that bypasses the DBus requirement entirely.
- Launch VS Code.- Open Settings by pressing
Ctrl + ,.- Typepasswordinto the search bar.- Locate the Window: Password Store setting.- Switch the dropdown fromgnome-libsecrettobasic.A quick warning: Thebasicsetting stores your tokens in an unencrypted JSON file located at~/.config/Code/User/globalStorage/. Only choose this if your local drive is already encrypted (e.g., via LUKS) or if you are working in a secure, private environment.
Solution 3: Fix DBus Session HandshakesIf the keyring is installed but VS Code still can't see it, your DBUS_SESSION_BUS_ADDRESS might be misconfigured. You can test this by launching VS Code inside a fresh DBus session.
Run this command from your terminal:
dbus-run-session -- code
If VS Code logs in successfully now, the issue lies with your session management. Check your ~/.bashrc or ~/.zshrc to ensure you aren't accidentally overwriting DBus variables.
Solution 4: The WSL2 WorkaroundWSL2 users often hit this wall because the Linux subsystem tries to find a Linux keyring that doesn't exist. Instead of fighting with a Linux-side keyring, bridge the gap by using the Windows Git Credential Manager (GCM).
- Ensure Git for Windows is installed on your Windows host.- In your WSL terminal, run this command to point Linux Git toward the Windows credential helper:``` git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"
## Verifying the FixTo make sure everything is working as intended, follow these steps:
- Close VS Code entirely—make sure no background processes are lingering.- Reopen VS Code and click the **Accounts** icon in the Activity Bar.- Select **Sign in with GitHub** and complete the flow in your browser.- If your profile picture appears and the error message stays hidden, you've successfully bridged the connection.## Staying Error-FreeTo prevent this from popping up on your next machine, consider adding `gnome-keyring` and `libsecret` to your standard setup scripts. For headless servers where security is paramount, skip the GUI login entirely and use a **Personal Access Token (PAT)** via the CLI. This keeps your workflow smooth without needing a secret service provider at all.

