### Checklist - [x] I'm using the latest version of the extension (Run `glab --version`) - Extension version: `glab 1.116.0 (e8436ca8a)`. Reproduced on 1.116.0. I have not run 1.117.0, but the flag registration and the rendering branches below are byte-identical at tag `v1.117.0`, so the behaviour is unchanged on the latest release. - [x] Operating system and version: macOS (Darwin 25.6.0, arm64) - [x] Gitlab.com or self-managed instance? gitlab.com - [ ] GitLab version (if self-managed) — n/a - [x] I have performed `glab auth status` to check for authentication issues — authenticated, no issues - [ ] Run the command in debug mode — omitted deliberately: this is local flag parsing, the API call succeeds and its response is irrelevant to the defect. `GLAB_DEBUG=true` output would add only auth headers. ### Summary `glab issue list` and `glab incident list` accept any value for their two output flags, including values outside the enumeration their own help advertises. Out-of-enum values are not rejected: exit code 0, empty stderr, and a silent fallback to the default renderer. Sibling commands reject the same value on a flag of the same name, so the inconsistency is within glab itself. ### Environment - OS: Darwin 25.6.0 arm64 - SHELL: /bin/zsh - TERM: xterm-256color - GLAB: glab 1.116.0 (e8436ca8a) ### Steps to reproduce ``` $ glab issue list --help | grep -i output -O --output Options: 'text' or 'json'. (text) -F --output-format Options: 'details', 'ids', 'urls'. (details) ``` Both enumerations are advertised as closed sets. Neither is enforced: | Command | Output | Exit code | stderr | | --- | --- | --- | --- | | `glab issue list -F json` | text table | 0 | empty | | `glab issue list -F anything` | text table | 0 | empty | | `glab issue list -F ""` | text table | 0 | empty | | `glab issue list -O anything` | text table | 0 | empty | `glab incident list` behaves identically — it is built on the same shared command. The same out-of-enum value on the same flag name is rejected elsewhere: ``` $ glab issue view 1 -F anything ERROR Invalid argument "anything" for "-F, --output" flag: must be one of [text json]. (exit 1) $ glab mr list -F anything ERROR Invalid argument "anything" for "-F, --output" flag: must be one of [text json]. (exit 1) ``` ### What is expected An out-of-enum value is rejected with a non-zero exit code and a message naming the flag and its accepted values, as `issue view` and `mr list` already do. ### What happens instead The value is accepted and ignored. The command renders its default format and reports success. ### Root cause In `internal/commands/issuable/list/issuable_list.go`, both flags are registered as bare strings, with no enum type: ```go issueListCmd.Flags().StringVarP(&opts.OutputFormat, "output-format", "F", "details", "Options: 'details', 'ids', 'urls'.") issueListCmd.Flags().StringVarP(&opts.Output, "output", "O", "text", "Options: 'text' or 'json'.") ``` The value is then only equality-tested at render time (`opts.Output == "json"`, `opts.OutputFormat == "ids"`, `"urls"`). Anything matching no branch falls through to the default renderer, and nothing ever compares the received value against the advertised enumeration. `internal/commands/issuable/view/issuable_view.go` instead goes through the shared `cmdutils.EnableJSONOutput(...)`, which registers a validated `-F, --output`. That is why `issue view` and `mr list` reject the value and `issue list` does not. The likely reason `issue list` sits outside that shared path is that it must keep the legacy `-F, --output-format`, whose removal was reported as a breaking change in #7491. That constraint explains the two flags; it does not require either of them to skip validation. ### Why this is worth fixing `-F` is the short form of the JSON output flag on `issue view` and `mr list`. That makes `glab issue list -F json` a natural thing to write — and glab accepts it in silence. The caller believes it holds JSON, receives a text table, and fails at parse time somewhere that does not name the cause. The same spelling is correct on three commands of the CLI and wrong on one, with no signal distinguishing them. This is worse for non-interactive callers (scripts, CI, AI agents) than a hard error would be: the failure surfaces far from the flag that caused it. We hit exactly this while following our own internal documentation, which prescribed `-F json` for listing issues. ### Suggested fix Register both flags as validated enums, so an out-of-enum value produces the same error as on `issue view` and `mr list`. `--output` could reuse whatever `cmdutils.EnableJSONOutput` registers; `--output-format` needs the equivalent over `details|ids|urls`. The existing `MarkFlagsMutuallyExclusive("output", "output-format")` is not in question and can stay as is. Rejecting values that are currently ignored is technically a behaviour change for anyone passing a bad value today — but those callers are already not getting the output they asked for. ### Duplicate search Searched this project's issues, all states, for: `output-format`, `output format`, `-F json`, `issue list json`, `issue list output`, `enum`, `flag validation`, `invalid value`, `unknown value`, `must be one of`, `Invalid argument`, `silently`, `silently falls back`, `output-format ids urls`. The closest neighbours all describe something else: - #7491 — removal of `--output-format` from `issue list` as a breaking change (the historical cause of the two flags, not the validation defect) - #8298 — whether to reuse an established output flag for a new format (naming, not validation) - #8241 — enum constraints missing from MCP tool schemas (different surface) - #8335, #8516 — key validation in `glab config set` (different surface)