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