Feature Request: Support for Custom Issue Status (Work Item Status) added in GitLab 18.2+
Summary
GitLab introduced Custom Issue Statuses (also called Work Item Statuses) in version 18.2, enabling more granular workflows such as “To Do,” “In Progress,” “In Review,” “Done,” or “Won’t Do.”
Currently, glab only supports the traditional binary states (open and closed) via commands such as:
glab issue update --state <state>
glab issue close
glab issue reopen
It would be highly beneficial for glab to surface and manage these new custom statuses directly from the CLI.
Problem / Motivation
Teams using the new GitLab work item model depend on multiple workflow states that go beyond just open or closed. At present, glab users cannot:
View an issue’s custom status (e.g., “In Progress”)
Change an issue’s status (e.g., from “To Do” → “In Review”)
Filter or list issues by a specific status
This creates a gap for users who rely on CLI-based workflows, scripts, or automation around GitLab issues.
Proposal
Add support for viewing, setting, and filtering by custom statuses New CLI Behaviors.
View issue status
glab issue view <id>
Example output:
Status: In Progress
Update issue status
glab issue update <id> --status "In Review"
Filter issues by status
glab issue list --status "In Progress"
Technical Notes
Use the GitLab GraphQL API (WorkItemState, WorkItemStateInput) to read and write status information.
Gracefully handle older GitLab instances or tiers that don’t expose the custom status feature.
Maintain backward compatibility with the existing --state open|closed flags.
References
GitLab Docs: Work Item Status
GitLab Engineering Handbook: Work Items Custom Status Design Doc