[Feature]: Support multiple GitLab users and instances from glab config #2643

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

Not sure

Problem or use case

Many users do not use glab with only one GitLab account or one GitLab instance.

For example, a user may have:

• a personal account on gitlab.com
• a work account on gitlab.com
• one or more self-hosted GitLab instances

Today, t3code appears to assume a single active GitLab/glab context. This makes it hard to use t3code reliably when the correct GitLab host or user depends on the current repository.

Proposed solution

Add support for detecting and using multiple GitLab users and instances from the existing glab configuration.

Ideally, t3code should be able to:

• read the available GitLab hosts/accounts configured in glab
• detect the correct GitLab instance from the current repository remote
• use the matching glab account/session for that repository
• allow the user to choose the correct GitLab account if detection is ambiguous
• remember the selected account/instance for the current project

Why this matters

This would make t3code usable for developers who work across multiple GitLab accounts or self-hosted GitLab instances.

It would reduce authentication confusion, avoid using the wrong GitLab account, and make GitLab workflows more predictable for users who already manage their GitLab access through glab.

Smallest useful scope

A first version only needs to support selecting the correct GitLab host/account for the current repository based on the configured glab hosts and the repository remote URL.

If multiple matches are possible, t3code could prompt the user to choose one and persist that choice locally for the project.

Alternatives considered

A workaround is to manually switch the active glab account or reconfigure glab before using t3code, but this is slow and error-prone when working across multiple repositories or GitLab instances.

Another workaround is to only use one GitLab instance with t3code, but that does not match how many developers use GitLab in practice.

Risks or tradeoffs

This may require careful handling of ambiguous repository remotes, expired glab sessions, and cases where the repository remote does not match any configured glab host.

There may also need to be a clear fallback when no valid GitLab account is available.

Examples or references

Example setup:

• gitlab.com with a personal account
• gitlab.company.com with a work account
• different repositories using different GitLab remotes

In this setup, t3code should use the correct glab account based on the current repository.

Contribution

• I would be open to helping implement this.