Repository navigation
Add --force flag to gh run cancel <run-id> #11073
Description
Describe the feature or problem you’d like to solve
Sometimes, a workflow run could not respond to regular cancellation, so we should be able to force it as outlined in https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28#force-cancel-a-workflow-run
Proposed solution
gh run cancel --force <run-id>
Activity
babakks commentedon Jun 10, 2025
Thanks for submitting this, @stepankuzmin! 🙏
Not surprisingly, @BagToad brought this up in a recent conversation we had. I'm wondering if there's any issue/discussion in the past, because I couldn't find similar requests among our old issues. @BagToad, in case you know some issue, could you please link this to it?
I think this is actually a good suggestion.
So, I'm going to put down the A/C for it.Let's first discuss the experience. See my comment below.
stepankuzmin commentedon Jun 10, 2025
Hey @babakks 👋
I've also tried to find any related information in the existing issues, but I didn't see anything.
babakks commentedon Jun 10, 2025
Before jumping to the A/C, I think we need to investigate the experience a bit more.
Currently,
gh run canceldoes not prompt for confirmation. But as of theforce-cancelendpoint docs:It's probably because force-cancelling a run might have side effects which wouldn't incur if the user goes through the ordinary cancel. So, I think at the CLI side, we should ask the user to confirm the forced cancel. And if there's a confirmation prompt, we might also want to have a way of bypassing it, e.g. with an extra
--yesoption to make it usable in automation use cases.So, the TLDR is we have these three options:
run cancel --forcedoes not prompt and works just like normal cancel.run cancel --forceprompts for confirmation.run cancel --forceprompts for confirmation, with an optional--yesflag for bypassing.Out of these, I'm more into the 3rd option, but let's see what other folks think.
@BagToad @andyfeller @williammartin What are your thoughts?
stepankuzmin commentedon Jun 10, 2025
run cancel --forcewith an optional--yesflag looks good 👍BagToad commentedon Jun 11, 2025
Thanks for pinging me on this @babakks ❤ I have been meaning to open an issue for this because it's a straightforward feature that only has API access right now. Thanks for opening this @stepankuzmin! It puts the CLI in a bit of a unique position to provide a better way to access this feature 😃
Now to the point, I actually don't want a
--yes. This is a double confirmation since the user has already told us they'd like to force it with--force.Another reason I'm not really worried is that the impact of a force-cancel is not that much different than a cancel. The difference in particular is that it overrides any conditionals in the workflow that may make it immune to a typical cancellation. The big one being the inclusion of
if: always()as a job condition which makes the workflow continue to run despite a cancellation.Most workflows will actually be cancellable without this flag, and besides most people are just running a straight API call to force cancel when they need to without really thinking about it, because they just want to cancel it.
And, the impact of an accidental job cancellation is contextual based on what a user is doing, but in general it simply means the workflow needs to be re-ran. It's not the end of the world, which is why we don't have a confirmation for a typical cancellation.
BagToad commentedon Jul 28, 2025
Acceptance Criteria
Given I have a workflow run in progress
When I run
gh run cancel --force <run-id>Then the workflow run is force-cancelled using the GitHub API’s force-cancel endpoint
When I run
gh run cancel --helpThen I see documentation for the
--forceflag describing its useankddev commentedon Aug 15, 2025
I'm working on this