Re-enable a GitHub Actions Workflow with gh workflow enable

Your scheduled job stopped running weeks ago and nobody noticed: gh workflow enable puts a disabled GitHub Actions workflow back to active. You will finish with the workflow restored and a check that you changed the intended repository. This guide uses GitHub CLI 2.87.3, installed from the gh package on this machine. Allow about five minutes if you already know the repository and workflow name.

The command changes remote repository state. You need an authenticated gh session and permission to administer Actions in the repository. No root access is needed, and you should not use sudo for this task.

1. Confirm the target repository

Make the repository explicit with --repo before enabling anything. The value accepts OWNER/REPO, or HOST/OWNER/REPO for a GitHub Enterprise host:

$ gh workflow list --all --repo EXAMPLE_OWNER/EXAMPLE_REPO --limit 50

Replace both uppercase placeholders with the repository you intend to change. The --all flag matters: ordinary listing hides disabled workflows, so leaving it out can make the workflow you need look missing.

Expected output is a table with columns such as Name, State and ID. Find the workflow whose state is disabled, then record its displayed name or numeric ID. You can also select it later by workflow file name, such as nightly.yml.

Checkpoint: If the list names the wrong organisation, repository or host, stop and correct --repo. Do not rely on whichever repository the surrounding shell directory happens to imply.

2. Check the selector before changing state

Use the workflow's exact displayed name, ID or file name. A name containing spaces must be quoted:

$ gh workflow view "Nightly maintenance" --repo EXAMPLE_OWNER/EXAMPLE_REPO

If you have the file name instead, use it as the selector:

$ gh workflow view nightly.yml --repo EXAMPLE_OWNER/EXAMPLE_REPO

These checks are read-only. They catch a similar name or a typo before the write. gh workflow enable accepts one optional selector. Leave it out and GitHub CLI opens an interactive choice when it has a usable terminal: handy for exploring, a poor fit for a script or a pasted runbook.

3. Enable the workflow

Run the command with the selector you confirmed:

$ gh workflow enable "Nightly maintenance" --repo EXAMPLE_OWNER/EXAMPLE_REPO

You can substitute the numeric ID:

$ gh workflow enable 123456789 --repo EXAMPLE_OWNER/EXAMPLE_REPO

On success, GitHub CLI normally prints nothing and exits with status 0. Underneath, it sends an enable request that sets the workflow state to active. A successful enable does not start a run, edit the workflow YAML or change its triggers.

Tip: In a shell script, capture the status immediately:

if gh workflow enable "Nightly maintenance" --repo EXAMPLE_OWNER/EXAMPLE_REPO; then
    printf '%s\n' 'Workflow enabled'
else
    status=$?
    printf 'Enable failed with status %s\n' "$status" >&2
    exit "$status"
fi

4. Verify that it is active

List workflows again, still including disabled entries, and inspect the target row:

$ gh workflow list --all --repo EXAMPLE_OWNER/EXAMPLE_REPO --limit 50

The workflow should now show an active state and stay visible in the list. For a less fragile check, ask for machine-readable fields:

$ gh workflow list --all --repo EXAMPLE_OWNER/EXAMPLE_REPO --json id,name,path,state --limit 50

Look for the matching id, name or path and confirm state is active. The JSON ordering is not a contract, so scripts should select fields by name rather than matching the whole line.

5. Handle the common failures

No repository can be determined. If gh workflow list says so, pass --repo OWNER/REPO explicitly. That also avoids acting on a repository inferred from a local checkout.
Workflow not found. If the API says so, repeat step 1 with --all and check the selector, repository owner and filename.
Authentication or permission error. Running as root will not fix it. Authenticate the intended GitHub account with the normal gh auth workflow, then make sure that account can administer Actions in the repository. Enabling a workflow needs write permission for Actions through GitHub's API.
Enabling is not running. Once the state is active, a workflow still runs only when an event in its YAML configuration occurs. For an immediate manual run, review the workflow's workflow_dispatch trigger and use the separate gh workflow run command. That is another state-changing action and is outside this guide.

Undo and safety boundary

If you enabled the wrong workflow, reverse it with the matching selector and repository:

$ gh workflow disable "Nightly maintenance" --repo EXAMPLE_OWNER/EXAMPLE_REPO

This stops the workflow running and hides it from the default list. Verify the result with gh workflow list --all.

Safety boundary: Disabling does not delete the workflow file, but it can stop scheduled or event-driven runs. Use it only when that interruption is intentional.

Done means

Target confirmed. The repository owner, name and host were checked before the write.
Selector matched. It named the intended workflow by name, ID or file path.
Clean exit. gh workflow enable returned status 0.
State verified. A follow-up list showed the workflow with state active.
No side effects. No run was triggered and no workflow file was edited unintentionally.