Add new flags gh issue create --[blocked-by/blocking] and gh issue edit --[add/remove]-[blocked-by/blocking] #11757

Activity

1. Next-Door-Tech

   added

   enhancementa request to improve CLIa request to improve CLI

   on Sep 17, 2025
2. github-actions commented on Sep 17, 2025

   

   github-actionsBot

   on Sep 17, 2025 – with GitHub Actions

   Contributor

   More actions

   Thank you for your issue! We have categorized it as a feature request, and it has been added to our backlog. In doing so, we are not committing to implementing this feature at this time, but, we will consider it for future releases based on community feedback and our own product roadmap.

   Unless you see the help wanted Contributions welcome label, we are not currently looking for external contributions for this feature.

   If you come across this issue and would like to see it implemented, please add a thumbs up! This will help us prioritize the feature. Please only comment if you have additional information or viewpoints to contribute.

   👍React with 👍2Reacted by Eddie Mitchell and Menerth
3. cliAutomation

   added

   needs-triageneeds to be reviewedneeds to be reviewed

   on Sep 17, 2025
4. babakks

   added

   needs-investigationCLI team needs to investigateCLI team needs to investigate

   gh-issuerelating to the gh issue commandrelating to the gh issue command

   on Nov 17, 2025
5. babakks commented on Nov 17, 2025

   

   babakks

   on Nov 17, 2025

   Member

   More actions

   Thanks for your feedback, @Next-Door-Tech and @dkaszews! 🙏

   I can see adding the support for blocking relationship provides value to the users. However, we need to dig a bit into it and see how the experience should look like.

   Note

   I'm going to cover both issues (i.e. this and #12152) here as they're closely related.

   API support

   As of now (November 2025), issues blocking/blocked-by relationship is only supported on github.com (i.e. not GHES). This means the implementation must perform feature detection to avoid hitting missing API endpoints. This applies to both REST and GraphQL endpoints.

   Both GraphQL and REST APIs support this feature via the following endpoints:

   • REST API:

     • GET /repos/OWNER/REPO/issues/NUMBER/dependencies/blocked_by: returns the list of issues blocking OWNER/REPO#NUMBER.
     • GET /repos/OWNER/REPO/issues/NUMBER/dependencies/blocking: returns the list of issues blocked by OWNER/REPO#NUMBER.
     • POST /repos/OWNER/REPO/issues/NUMBER/dependencies/blocked_by: adds a blocking/blocked-by association.
     • DELETE /repos/OWNER/REPO/issues/NUMBER/dependencies/blocked_by/BLOCKING_NUMBER: removes a blocking/blocked-by association.

   • GraphQL:

     • Query repository.issue.blockedBy: returns the list of blocking issues.
     • Query repository.issue.blocking: returns the list of blocked issues.
     • Mutation addBlockedBy: adds a blocking/blocked-by association.
     • Mutation removeBlockedBy: removes a blocking/blocked-by association.

   Few remarks:

   1. The API endpoints only accept issue IDs (i.e. databaseId which is globally unique number). This is perhaps to support cross-repo relationships with a simple interface.
   2. The association is only supported between issues (not PRs). This results in an implementation challenge, explained later on.
   3. The API endpoints do not support batch operations. The caller has to repeat it if they're adding more than one association. In rare cases, where a user wants to add a large number of associations, they may get rate-limiter errors, resulting in an ill state.

   CLI experience

   This feature applies to issue create, issue edit and issue view commands.

   1. issue create

   Interactive

   Warning

   Providing interactive support for this feature is challenging. I mean, just prompting for issue numbers/URLs doesn't yield much value. As a user I'd prefer to see a list of issues that I can pick (like the web GUI), and this obviously is not easy to implement. Let alone the fact that GUI does allow you to pick issues from other repositories.

   Non-interactive

   With these repeatable options:

   • --blocked-by <NUMBER | URL | REFERENCE>
   • --blocking <NUMBER | URL | REFERENCE>

   The arguments can be either:

   • An number (not ID) resolving to an issue (not PR) in the same repo that the new issue is being created in.
   • A URL resolving to an issue (not PR) to support cross-repo associations.
   • A reference in the owner/repo#number format to support cross-repo associations.

   2. issue edit

   Interactive

   Warning

   The same challenge as above.

   Non-interactive

   With these repeatable options:

   • --add-blocked-by <NUMBER | URL | REFERENCE>
   • --add-blocking <NUMBER | URL | REFERENCE>
   • --remove-blocked-by <NUMBER | URL | REFERENCE>
   • --remove-blocking <NUMBER | URL | REFERENCE>

   3. issue view

   Interactive

   Currently, we don't show closing PRs in the interactive view, so we might want to keep the same behaviour for blocking/blocked-by associations. If not, we can display two group of URLs/references; blocking and blocked-by.

   Non-interactive; plain (e.g. piped output)

   issue view currently prints a minimal machine readable output like this:

   title:     foo
   state:     OPEN
   author:    johndoe
   labels:    foo, bar, baz
   comments:  4
   assignees:
   projects:
   milestone:
   number:    99999
   --
   [BODY]
   

   We can add two more entries like:

   blocking: owner/repo#number, owner/repo#number, owner/repo#number
   blocked-by: owner/repo#number, owner/repo#number, owner/repo#number
   

   Or even omit the association data since they're niche metadata. 🤷

   Non-interactive; JSON

   I can think of two new JSON fields to hold the full URL of the associated issues:

   {
     "id": "99999999",
     // ...
     "blockingIssues": [
       {
         "url": "https://github.com/OWNER/REPO/issues/99999"
       }
     ],
     "blockedByIssues": [
       {
         "url": "https://github.com/OWNER/REPO/issues/99999"
       }
     ]
   }

   The URL is necessary to allow cross-repo links.

   Implementation challenges

   • Feature detection: As noted above, the feature is only available on github.com. So feature detection is necessary.
   • Shared code with pr commands: issue create and issue edit reuse some components from pr commands to supply metadata of the subject "issue". Since the API only supports the association between issues, we'd have to handle this separately in issue commands. I don't know if there's any plan to support such associations with PRs, but if there'll be such a thing, then we'd probably have to go through refactoring and making things reusable.
   • Complicated interactive flow: Displaying a dynamic list of issues to pick from is kind of new to gh and needs careful design, especially regarding accessibility.

   Notes for the team

   It's a nice addition, but at the same time a complicated one. See the short list of the challenges just above this.
6. babakks

   removed

   needs-investigationCLI team needs to investigateCLI team needs to investigate

   on Nov 17, 2025
7. dkaszews commented on Nov 17, 2025

   

   dkaszews

   on Nov 17, 2025

   More actions

   The API endpoints do not support batch operations

   It also seems to be the issue that there is no API for getting all blocked/blocking issues (like you can in web search), best I could find is to iterate over all issues and checking if they return a non-empty array, which is really suboptimal for large repositories.

   👍React with 👍3Reacted by Babak K. Shandiz, Noboru Sugiyama and Nadav Timor
8. BagToad commented on Apr 8, 2026

   

   BagToad

   on Apr 8, 2026

   Member

   More actions

   Issue relationship flags are in progress, covering --blocked-by/--blocking on create, and --add-blocked-by/--remove-blocked-by/--add-blocking/--remove-blocking on edit. The full design is up for review at #13120. If you have feedback on the proposed flags or behavior, please comment there!
9. BagToad

   closed this as completedin #13057on Jun 4, 2026
10. github-actions

    removed

    needs-triageneeds to be reviewedneeds to be reviewed

    on Jun 4, 2026