### Checklist - [x] I'm using the latest version of the extension (Run `glab --version`) - Extension version: `glab 1.114.0 (4d7c6cda)` - [x] Operating system and version: Linux 7.1.8-1-default x86_64 (openSUSE Tumbleweed) - [x] Gitlab.com or self-managed instance? _gitlab.com_ - [x] GitLab version (if self-managed): n/a - [x] I have performed `glab auth status` to check for authentication issues - [x] Run the command in debug mode: no debug output is relevant — the failure happens in local flag validation, before any API call ### Summary `glab config set` validates its `<key>` argument against an allow-list that has drifted out of sync with the keys glab actually supports. Two independent defects fall out of that: 1. **`glab_pager` and `debug` are read at runtime but cannot be set.** `glab config` documents `glab_pager` in its "Current respected settings" list, and `cmd/glab/main.go` reads both keys — but neither has an entry in `KeySchema`, so `config set` rejects them. 2. **Every schema alias is rejected**, including `visual` (also documented in `glab config`), `gitlab_token`, `gitlab_host`, `prompt_disabled` and a dozen more. `IsKnownKey` indexes only `KeyDef.Name` and never resolves aliases — even though `fileConfig.Set` and `LocalConfig.Set` both already call `ConfigKeyEquivalence` and would handle the alias correctly if the gate let it through. This is unintended fallout from #8335, implemented in 19c91cc9d7611e782efa388c4050f552db18f487 and shipped in v1.102.0. Before that commit `config set` accepted any key, and `glab config set glab_pager "less -R"` worked. Two details of #8335 are worth revisiting here, because both bear directly on this bug — see "Relationship to #8335" below. ### Environment - OS: Linux 7.1.8-1-default x86_64 - SHELL: /bin/zsh - TERM: xterm-256color - GLAB: glab 1.114.0 (4d7c6cda) Other: reproduced against an isolated configuration directory via `GLAB_CONFIG_DIR`, so no pre-existing local configuration is involved. ### Steps to reproduce ```shell glab config set glab_pager "less -R" # documented in `glab config`, rejected glab config set visual vim # documented in `glab config`, rejected glab config set gitlab_token xxxxx # documented alias of `token`, rejected glab config set editor vim # works, for contrast ``` `glab config` lists both `glab_pager` and `visual` under "Current respected settings", so the error message's advice — "run `glab config` to see the supported keys" — points at a list that contains the very key it just refused. ### What is the current _bug_ behavior? ```console $ glab config get glab_pager $ glab config set glab_pager "less -R" ERROR "Glab_pager" is not a recognized glab config key, run `glab config` to see the supported keys. ``` Every one of these is refused with the same error, in an isolated `GLAB_CONFIG_DIR`: | Key | Kind | Status | | --- | --- | --- | | `glab_pager` | read by `cmd/glab/main.go:78`, documented in `glab config` | rejected | | `debug` | read by `cmd/glab/main.go:64`, undocumented | rejected | | `visual` | alias of `editor`, documented in `glab config` | rejected | | `glab_editor` | alias of `editor` | rejected | | `gitlab_host`, `gitlab_uri`, `gl_host` | aliases of `host` | rejected | | `prompt_disabled` | alias of `no_prompt` | rejected | | `gitlab_token`, `oauth_token` | aliases of `token` | rejected | | `gitlab_api_host` | alias of `api_host` | rejected | | `gitlab_subfolder` | alias of `subfolder` | rejected | | `gitlab_ssh_host` | alias of `ssh_host` | rejected | | `git_remote_url_var`, `git_remote_alias`, `remote_nickname`, `git_remote_nickname` | aliases of `remote_alias` | rejected | | `editor` | canonical name | accepted | `glab config get glab_pager` prints nothing rather than reporting an unknown key, because `get` performs no validation at all and `fileConfig.Get` resolves any key present in the YAML. The asymmetry makes the failure look like a typo on the user's part. Cosmetic aside: the error renders the key as `"Glab_pager"`. glab formats the raw key with `%q`, so the capitalization is introduced downstream by `fang.DefaultErrorHandler`, which `internal/cmdutils/errors.go:58` delegates rendering to. Minor, but it adds to the impression that the key was mangled. ### What is the expected _correct_ behavior? - `glab config set glab_pager "less -R"` succeeds — it is documented as supported and is read on every invocation. - `glab config set visual vim` succeeds and writes to the canonical `editor` key, matching what `Set` already does with aliases. - Any key that `glab config` documents is settable, and any key `glab config set` refuses is genuinely unsupported. ### Relevant logs and/or screenshots ```console $ GLAB_CONFIG_DIR="$(mktemp -d)" glab config set --global visual vim ERROR "Visual" is not a recognized glab config key, run `glab config` to see the supported keys. ``` ### Relationship to #8335 [#8335](https://gitlab.com/gitlab-org/cli/-/work_items/8335) is where this validation was specified, and two of its details are relevant: **The key sweep was incomplete, and never covered aliases.** Step 1 of #8335 enumerates "keys read by the codebase but absent from the lock" and lists `client_id`, `ca_cert`, `client_cert`, `client_key`, `skip_tls_verify`, `use_keyring`, `job_token`, `user`, `auto_download`, `branch_prefix`. `glab_pager` and `debug` are read by `cmd/glab/main.go` but appear in neither that list nor the resulting `KeySchema`. Aliases are not discussed in #8335 at all, so the gate that shipped never accounted for them. **The shipped behavior is stricter than what #8335 recommended.** Step 2 offered two options — "warn-but-allow" or "reject by default with a `--force` escape" — and concluded: _"Suggested starting point: warn-but-allow, reassess after some time in the field."_ It also flagged that reject-by-default "breaks users who have stray keys today". What shipped is reject-by-default **with no `--force` escape**, which is the harsher of the two options minus its safety valve. Had warn-but-allow shipped as suggested, this bug would have been a warning rather than a hard failure. Also related, both in the opposite direction (schema keys missing from the docs, rather than documented keys missing from the schema): - [#8375](https://gitlab.com/gitlab-org/cli/-/work_items/8375) (open) — generate the env-var and config doc surfaces from `KeySchema`. That would prevent this class of drift structurally. - [#8391](https://gitlab.com/gitlab-org/cli/-/work_items/8391) (closed) — `git_protocol` missing from `glab config --help`. ### Possible fixes Two distinct changes, because the two defects have different causes. **1. Register the missing keys** in `KeySchema` ([`internal/config/schema.go`](https://gitlab.com/gitlab-org/cli/-/blob/main/internal/config/schema.go)): add `KeyDef` entries for `glab_pager` and `debug`, completing the sweep specified in step 1 of #8335. Two caveats for whoever picks this up: - `UserSettable: true` also feeds `userSettableKeys` → `rootConfig()`, so the new keys get seeded into the blank configuration and the `config_file_test.go` fixtures will need updating. - Leave `EnvVars` unset on `glab_pager`. The default `strings.ToUpper(canonical)` already yields `GLAB_PAGER`; adding `PAGER` there would collide with the fallback `iostreams.PagerCommandFromEnv()` already applies at a different layer in `cmd/glab/main.go`. **2. Resolve aliases in the gate** — one line in [`internal/config/known_keys.go`](https://gitlab.com/gitlab-org/cli/-/blob/main/internal/config/known_keys.go): ```go func IsKnownKey(key string) bool { _, ok := KnownKeys()[ConfigKeyEquivalence(key)] return ok } ``` Both write paths (`fileConfig.Set`, `internal/config/config.go:498`, and `LocalConfig.Set`, `internal/config/local_config.go:90`) already normalise through `ConfigKeyEquivalence`, so nothing downstream needs to change. **3. Optionally, reconsider the strictness** — either soften to the warn-but-allow starting point #8335 actually recommended, or add the `--force` escape that its reject-by-default option was specified to carry. Any allow-list will drift again eventually; whether that drift costs users a warning or a hard failure is the decision worth making deliberately. **Why this was not caught.** The "Current respected settings" list in [`internal/commands/config/config.go`](https://gitlab.com/gitlab-org/cli/-/blob/main/internal/commands/config/config.go) is a hand-written heredoc, entirely disconnected from `KeySchema` — the same structural problem #8375 proposes to fix, seen from the other side. Meanwhile `internal/config/known_keys_test.go` only spot-checks a hardcoded subset of key names: nothing cross-checks the documented list against `IsKnownKey`, and nothing asserts that aliases are settable. Step 3 of #8335 anticipated exactly this and suggested "a CI lint or test that diffs `cfg.Get(..., "<key>")` literals against the lock to catch drift"; that check does not appear to have been implemented, and it would have caught both defects.