GitHub CLI 2.94.0 allows the gh issue command to handle issue types, sub-issues, dependencies, and more.

GitHub CLI 2.94.0 allows the gh issue command to handle issue types, sub-issues, dependencies, and more.

GitHub CLI 2.94.0 now allows you to handle issue types, sub-issues, and dependencies from the CLI. This article organizes practical usage and use cases for this update, which can further streamline team operations and automation.
2026.06.19

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 null or 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:

Share this article