GitHub CLI 2.94.0 allows the gh issue command to handle issue types, sub-issues, dependencies, and more.
This page has been translated by machine translation. View original
Hey there! I'm Yuji Nishimura from the Operations Department!
GitHub CLI 2.94.0 was released on 2026-06-10, making it possible to handle Issue types, sub-issues, and dependencies with gh issue.
While these could previously be configured through the GitHub UI, working with them via CLI required using gh api or GraphQL directly. In v2.94.0, they've been integrated into the standard commands: gh issue create / edit / list / view.
This article reviews the changes around gh issue and organizes how they might be useful in practice.
What Changed
In GitHub CLI 2.94.0, the following structured Issue management features have been added to gh issue.
| Target | What's now possible |
|---|---|
| Issue types | Specify a type when creating or editing Issues |
| sub-issues | Handle parent issues and sub-issues from the CLI |
| dependencies | Handle blocked-by / blocking dependencies from the CLI |
| list / view | Filter by type and retrieve parent-child relationships and dependencies as JSON |
The official GitHub Changelog also mentions the context of coding agents operating GitHub through gh. This update is meaningful not only for humans using it in the terminal, but also for use cases where CI or agents read Issue structures.
Cases Affected
- Using Issue types to categorize Bug / Feature / Task, etc.
- Breaking down large pieces of work using parent Issues and sub-issues
- Representing work dependencies with blocking / blocked-by
- Wanting to move Issue creation and triage to CLI or scripts
- Wanting AI agents to read Issue structures and determine the next action
Conversely, for personal repositories that don't use Issue types or sub-issues, day-to-day operations are unlikely to change immediately. v2.94.0 is best understood as an update that makes it easier to incorporate GitHub's new Issue management features into team workflows and automation.
Trying It Out
Environment
- macOS
- GitHub CLI 2.94.0
Attaching type, parent, and dependencies at create time
Looking at gh issue create --help, the following flags had been added.
--blocked-by numbers Mark the new issue as blocked by these issue numbers or URLs
--blocking numbers Mark the new issue as blocking these issue numbers or URLs
--parent number Add the new issue as a sub-issue of the specified parent number or URL
--type name Set the issue type by name
As shown in the release notes examples, you can now specify types, parent-child relationships, and dependencies when creating Issues.
gh issue create --type Bug
gh issue create --parent 100
gh issue create --blocked-by 200
For example, you can call gh issue create --type Bug from a bug report template or an internal tool to have it pre-classified at creation time.
The same applies to sub-issues. You can create a parent issue for large tasks and attach detailed tasks to it via CLI.
Fixing the structure of existing Issues with edit
The gh issue edit command for editing existing Issues also has corresponding add/remove flags.
--add-sub-issue number
--remove-sub-issue number
--parent number
--remove-parent
--add-blocked-by number
--remove-blocked-by number
--add-blocking number
--remove-blocking number
--type name
--remove-type
Operations that previously required opening an Issue in the browser to set parent-child relationships and dependencies can now be handled from the CLI.
For example, if you later realize "this Issue was part of a parent task," you can fix it like this:
gh issue edit 123 --parent 100
The same applies to dependencies.
gh issue edit 123 --add-blocked-by 200
To avoid modifying real data, this article only covers checking the help output, but the command structure is available for both creation and editing.
Structure also appears in list / view JSON
The read side has changed as well. In gh issue list --help, we could confirm the --type filter and new JSON fields.
--type name Filter by issue type name
JSON FIELDS
assignees, author, blockedBy, blocking, body, closed, closedAt,
closedByPullRequestsReferences, comments, createdAt, id, isPinned, issueType,
labels, milestone, number, parent, projectCards, projectItems, reactionGroups,
state, stateReason, subIssues, subIssuesSummary, title, updatedAt, url
Let's read a few fields as JSON from the public repository cli/cli.
gh issue list \
--repo cli/cli \
--limit 1 \
--json number,title,issueType,parent,subIssuesSummary,blockedBy,blocking \
--jq '.[0]'
Here is an example of the output.
{
"blockedBy": {
"nodes": [],
"totalCount": 0
},
"blocking": {
"nodes": [],
"totalCount": 0
},
"issueType": null,
"number": 13680,
"parent": null,
"subIssuesSummary": {
"completed": 0,
"percentCompleted": 0,
"total": 0
},
"title": "gh pr checks: blank summary when all checks were cancelled"
}
When the target Issue has no type or parent-child relationships, issueType and parent will be null and subIssuesSummary will be 0, but the significant part is that these are now readable as JSON fields. This can be used to inspect Issue structure in CI, or to let agents read "what is blocking this Issue."
How to Use It in Practice
The gh issue updates in GitHub CLI 2.94.0 make it easier to support workflows like the following, now that Issue structure can be read via list / view.
Using parent-child relationships in reports
Since parent, subIssues, and subIssuesSummary can be read as JSON, you can incorporate parent Issue progress into regular reports.
For example, generating a weekly count of remaining sub-issues per parent Issue, or checking for incomplete sub-issues before a release.
Automatically checking blocking relationships
An Issue is marked as complete, but its dependency is still open. Or blocked-by relationships remain before work has started. These kinds of states become easier to detect with CI or scheduled jobs.
Notes
Here are some notes based on what was confirmed in this article.
- Issue types need to be configured on the organization side
- Issue types / sub-issues apply to GitHub.com and GHES 3.17+
- relationships apply to GitHub.com and GHES 3.19+
- Since create / edit commands modify real data, this article only covers checking the help output
- When reading JSON from public repositories where Issues have no type or parent-child relationships, the relevant fields will be
nullor empty
Summary
With GitHub CLI 2.94.0, Issue types, sub-issues, and dependencies can now be handled through standard gh issue commands.
Not only can sub-issues be created and edited, but parent-child relationships and dependencies also appear in the JSON output of list / view. This makes GitHub's Issue structure more readable not just for humans, but also for CI and agents.
For teams already using Issue types and sub-issues, upgrading to GitHub CLI 2.94.0 or later seems worthwhile.
I hope this is helpful to someone.
Reference links: