# Multiple GitLab identities with `glab`
**This machine carries more than one GitLab account**, and `glab` stores exactly one
credential per host: `~/.config/glab-cli/config.yml` holds `hosts:` → `gitlab.com` → a
`user:` and a `token:`. A second `glab auth login --hostname gitlab.com` therefore
*replaces* the first rather than adding to it, and that is the trap this note exists for:
releasing `thyseus/tix` needs the `thyseus` account, while the machine's default `glab`
identity may be a different one (here `davidgrosse`).
The failure it produces is a bare **403** from the one call that writes:
```bash
$ mise run package-binary
# … compiles successfully, packages the tarball, then:
# Post https://gitlab.com/api/v4/projects/thyseus%2Ftix/releases: 403 {message: 403 Forbidden}
```
The project is **public**, so an account that cannot release can still read it — which is
why the error arrives at the release, after a successful build, rather than at the start.
`mise run package-binary`'s last step is exactly that call:
`glab release create "v$TIX_VERSION" "$name.tgz"`.
## The three variants
### 1. A token for one command — nothing stored, nothing replaced
```bash
GITLAB_TOKEN=<thyseus PAT> mise run package-binary
```
`glab`'s own `auth login --help` states the rule: if `GITLAB_TOKEN`,
`GITLAB_ACCESS_TOKEN` or `OAUTH_TOKEN` are set, they take precedence over the stored
credentials. The default identity is untouched and nothing has to be undone afterwards.
The cost is that every invocation must carry the token from somewhere that is not your
shell history.
### 2. A second config directory — a real second identity
```bash
GLAB_CONFIG_DIR=~/.config/glab-thyseus glab auth login --hostname gitlab.com # once
GLAB_CONFIG_DIR=~/.config/glab-thyseus mise run package-binary # from then on
```
`GLAB_CONFIG_DIR` redirects the whole configuration, so the second account gets its own
`config.yml` — and its own keyring entry — and the two never see each other. Verified on
`glab 1.119.0`: pointed at an empty directory, `glab auth status` reports
`401 Unauthorized` and writes a fresh config there.
**This is the variant in use here, and it works.** `~/.config/glab-thyseus` is logged in
as **`thyseus`** while the default `~/.config/glab-cli` remains **`davidgrosse`**:
```bash
$ GLAB_CONFIG_DIR=~/.config/glab-thyseus glab auth status
gitlab.com
✓ Logged in to gitlab.com as thyseus (/home/thyseus/.config/glab-thyseus/config.yml)
$ glab auth status
gitlab.com
✓ Logged in to gitlab.com as davidgrosse (/home/thyseus/.config/glab-cli/config.yml)
```
`mise run package-binary` succeeds under the first, and **v0.8.0 was released from this
machine through it**: `refs/tags/v0.8.0` is on the remote and the project's release list
carries it above `v0.7.0`, `v0.6.0` and the rest. To save typing, a shell function or an
alias for the release task is enough:
```bash
glab-thyseus() { GLAB_CONFIG_DIR=~/.config/glab-thyseus command glab "$@"; }
```
Setting `GLAB_CONFIG_DIR` in `mise.toml`'s `[env]` would make `mise run package-binary`
in this repository always use that identity. It is deliberately **not** done: it would
write a path outside the repository, belonging to one machine, into the project's own
configuration.
### 3. Replacing the stored credential — the variant to avoid
```bash
glab auth login --hostname gitlab.com # overwrites the gitlab.com entry
```
Convenient, and destructive to the other identity: the configuration holds one credential
per host, so this is the variant that *sacrifices* the account already there.
## What the token must be
- **The account that owns the namespace** — `thyseus` for `thyseus/tix`. Creating a
release needs Developer or above on the project, and the releases already published
there were authored by `thyseus`.
- **`api`-scoped.** Reading a *public* project proves nothing about the scope, so a 403
that survives the identity change is a scope question, not a wrong-account one.
- **Unrelated to the commit identity.** `glab auth status` reports that git operations
use SSH, so whichever account the API uses, `user.name` / `user.email` (here
`thyseus@pm.me`, "Herbert Maschke") are unaffected. The *author* of a release comes
from the token, not from the commits.
## Secrets
`glab` stores the token in **plaintext** in whichever config file is in effect — it says
so itself when reporting the status — and offers `glab auth login` again, or
`--use-keyring`, to move it into the operating system keyring. Prefer that: a config
directory under a home directory that gets copied, synced or pasted is a token on the
loose. When a token has been exposed — logged, screenshotted, pasted into a chat or a
ticket — revoke and reissue it rather than carrying on with it.