GitLab Forge's token incorrectly applied to other projects

[nshcr]

Version

0.16.10

Operating System

macOS

Distribution Method

dmg (Mac OS - Apple Silicon)

Describe the issue

When setting up a GitLab Forge for one project and configuring its token, then switching to another project, GitButler creates another new keychain entry for the switched project that stores the same token as the previous one, even if this project hasn't configured a Forge yet.

At first, I thought this might be a convenient design choice — automatically reusing an existing token to avoid re-entering it sounds reasonable. However, I later realized this is likely a token reuse bug.

Changing the token for one project causes all other projects' corresponding GitLab tokens to change as well, which doesn't make sense when different projects may use different GitLab instance URLs or accounts.

The video showing the reproduction steps is attached below: both demo1 and demo2 projects were removed and re-added before testing.

This bug doesn't just affect two projects — as long as one GitLab Forge is configured, the token eventually spreads to all projects in the list, generating multiple duplicate keychain entries.

Additionally, deleting a GitLab token results in a flood of "No matching entry found in secure storage" errors.

This issue also occurs in the latest nightly build.

How to reproduce (Optional)

Screen.Recording.2025-10-23.at.02.49.32.mov

Expected behavior (Optional)

No response

Relevant log output (Optional)

[nshcr]

I originally wanted to record the changes in the keychain as well, but it seems GitButler reads and writes the GitLab token so frequently that it crashes my keychain every time, so this might be another area that needs optimization.

[Byron]

Thanks so much for reporting! I noticed a whole bunch of other things while reproducing this 😅.

Maybe @estib-vega can take a look, maybe it's an easy fix? Or maybe it's a good incentive to put more of the token handling into the backend, similar to how it was done for GitHub, even though that sounds like a whole lot more effort.

[estib-vega]

Hey there! Thanks for raising this.

I'm actually not sure to what extent was this implemented as a feature to easily share the GitLab token across projects, but definitely the flow for deleting it needs some love.

More context on how we'll improve this

We're currently undergoing a migration of the Forge integrations to the rust side. We're starting with GitHub since that's the service we use the most, and then right after we'll bring GitLab into the new world.

This will allow the user to do account management in a similar fashion to GitHub and it will give us the opportunity to verify that the UX of configuring a forge provider on a per project basis works as expected.

[nshcr]

@estib-vega Thanks for your reply!

I think that it's better not to share GitLab tokens across projects — having them managed globally would be a much better idea.

Of course, if the GitLab integration could work the same way as the current multi-GitHub account setup, that would be fantastic!

Each GitLab instance URL and its token could form a configuration pair. A global settings page could allow users to manually manage multiple such configurations, and then select which one to use for each project's GitLab forge.

That way, the issue described here wouldn't exist.

[Byron]

You have to know that we plan to put much of the application configuration into git configuration instead. That way, people can override them using standard Git mechanisms, like includeIf.
So I hope that anything we build can eventually be moved there, and we can avoid building special cases for this or build them with this in mind.

[nshcr]

Linking to this issue: #9995

They're not duplicate issues — currently, only tokens are reused, and no other settings are shared across projects.

However, I think both can be closed once the GitLab integration improvements are completed.