L
Lanin Min
1. Summary of the Request
Please fix the authentication mechanism on Linux to prevent an infinite login loop on Arch-based systems. The application currently fails to use two standard authentication methods:
  1. It does not correctly interface with the system's
    libsecret
    credential store (even when it's fully functional).
  2. It completely ignores the
    CODEIUM_ACCESS_TOKEN
    environment variable, which should serve as a primary login method.
This makes it impossible to log into and use the Windsurf IDE on affected systems.
2. System Environment
*
Operating System:
Arch Linux
*
Windsurf Version:
1.12.28
*
Authentication Backend:
libsecret
(managed by
gnome-keyring-daemon
)
3. Detailed Problem Description & Troubleshooting Journey
The user experiences an infinite login loop. After successfully authenticating via the browser or entering a manual token, the IDE returns to the "Sign In" prompt without ever completing the login.
Our in-depth troubleshooting has isolated the problem to the Windsurf application itself, not the user's system configuration.
Phase 1: Identifying the Credential Storage Failure
* Initial logs consistently showed the application was making unauthenticated requests, leading to the gRPC error:
metadata.api_key: value length must be at least 1 characters
.
* We traced this back to a failure in the application's attempt to retrieve a stored token. The logs repeatedly showed:
[secrets] no secret found for key: windsurf_auth.sessions
.
* We initially confirmed that the system's
gnome-keyring-daemon
was in a non-responsive state (the
secret-tool
command would hang). We successfully guided the user through a full reset of the keyring service.
*
Crucial Finding:
After fixing the OS keyring (verified by successfully running
secret-tool store
and
secret-tool lookup
), Windsurf **still failed with the exact same
[secrets] no secret found
error**. This definitively proves the issue is not with the OS keyring itself, but with Windsurf's inability to correctly communicate with the
libsecret
service.
Phase 2: Attempting the Environment Variable Workaround
* To bypass the broken secret store integration, we used the documented
CODEIUM_ACCESS_TOKEN
environment variable.
* We set the variable in
~/.bashrc
and verified with
echo $CODEIUM_ACCESS_TOKEN
that it was correctly exported to the shell environment.
* We then performed a full cleanup (
rm -rf ~/.config/Windsurf ~/.codeium
) and launched the application from the terminal that had the variable loaded.
*
Crucial Finding:
The application
completely ignored the environment variable
. It did not log in automatically and instead prompted for a new login. The application's own verbose logs even show the
CODEIUM_ACCESS_TOKEN
variable is present in the environment it receives, yet it still prioritizes the failed keyring lookup.
4. Summary of the Bug
There are two distinct failures in the authentication logic:
  1. **Failure to Use
    libsecret
    :** The application does not correctly interface with a standard Linux
    libsecret
    keyring. It fails to read from or write to it, even when the service is fully operational.
  2. **Failure to Honor
    CODEIUM_ACCESS_TOKEN
    :** The application ignores the presence of the
    CODEIUM_ACCESS_TOKEN
    environment variable at startup, defeating its purpose as a reliable authentication method and workaround.
5. Proposed Solution / Feature Implementation
Modify the authentication logic with the following priority order, which is standard for CLI and server-backed desktop applications:
  1. **On startup, first check for the
    CODEIUM_ACCESS_TOKEN
    environment variable.** If it is present, use it to authenticate the session immediately and bypass any other checks.
  2. If the environment variable is not present,
    then attempt to retrieve the token from the system's
    libsecret
    keyring.
  3. If both methods fail,
    only then should the application present the user with the "Sign In" prompt.
Implementing this logic will fix this critical bug and make the application usable on a wider range of Linux configurations.