GitDash
Back to blog

August 3, 2026

GitHub Actions Holds Workflow Runs for Approval: How to Review a Suspicious Run Safely

Learn what GitHub’s new workflow approval hold means, how to inspect a suspicious Actions run, and when it is safer to reject than approve.

A workflow gate holding a stream of code while a reviewer checks its permissions and origin

A workflow run that suddenly waits for approval is easy to misread as a broken check. On GitHub.com, it may be a new supply chain protection instead. Since July 28, 2026, GitHub Actions can hold certain potentially malicious workflow runs in public repositories before they start. A collaborator with write access must review and approve the run through an authenticated web session before execution continues. GitHub’s announcement says the protection is automatic and currently applies to public repositories on GitHub.com.

This changes the right response from “click approve so CI turns green” to “review the code that would run, the permissions it requests, and the event that triggered it.” Approval is a security decision, not a routine retry.

What the hold means

The hold happens before the workflow executes. The workflow file, scripts, actions, and permissions in the proposed run have not been given a runner yet. When an authorized collaborator approves it, the run proceeds normally. GitHub does not require a repository setting for this specific protection.

  • The feature is currently for public repositories on GitHub.com.
  • GitHub Enterprise Server does not add this protection at this time.
  • The run needs approval from a collaborator with write access.
  • Approval must be submitted through an authenticated web session.
  • The hold is selective. It does not mean every workflow run needs a human gate.

This protection sits alongside other controls. GitHub’s workflow execution protection guide covers settings that limit which actors and events can run workflows, including why changes to workflow files deserve extra attention.

First, confirm what changed

Open the run and identify the exact commit, branch, actor, and event. A run from a trusted maintainer’s expected branch is different from a new workflow pushed by an account you do not recognize. A pull request from a fork, a recently transferred repository, and an unexpected workflow edit all deserve a slower review.

  • Compare the workflow file with the previous revision.
  • Check whether the workflow adds a new action, shell command, download, or script.
  • Look for changes to permissions, especially contents, pull requests, packages, deployments, and the ID token.
  • Check whether the job can access secrets, environments, cloud roles, or write tokens.
  • Confirm that the requested runner, containers, and services are expected for the job.

Review permissions before approving

A workflow can be useful and still ask for more access than it needs. Start from a small permission set and add only what the job requires. For many read-only checks, this is a sensible baseline:

permissions:\n  contents: read

If a job publishes a release, comments on a pull request, or requests a cloud identity token, the workflow may need more permissions. That is not automatically malicious, but the extra capability should have a clear reason in the review. OIDC access deserves special care because it can exchange a GitHub-issued token for access to a cloud role.

Inspect actions and downloaded code

A workflow can execute code from actions, local scripts, package managers, downloaded archives, and containers. Do not stop at the top-level YAML. Follow the path from the trigger to the first command that can execute code.

  • Prefer actions pinned to a reviewed commit when your repository policy allows it.
  • Read the action’s repository and release history before adding a new dependency.
  • Check shell commands that pipe remote content into an interpreter.
  • Check package install commands and scripts that run during installation.
  • Treat a new third-party action with access to secrets as a separate security review.

The goal is not to prove that a workflow is harmless from one glance. The goal is to gather enough context to decide whether the run belongs in your trust boundary.

When not to approve

Leave the run held when the change is unexplained, the actor is unexpected, the workflow asks for broad write access, or the job would expose credentials to code you have not reviewed. Ask the author to explain the change in the pull request, or close and recreate the workflow from a trusted branch.

  • Do not approve just to inspect the logs. The job has not earned access to the runner yet.
  • Do not paste secrets into a workflow to help it pass a failing check.
  • Do not use a broad wildcard cloud trust policy as a shortcut for a blocked deployment.
  • If a malicious change may already have run elsewhere, rotate affected credentials and review recent workflow runs.

A safer approval checklist

  • I recognize the actor and expected branch.
  • I reviewed the workflow diff, not only the workflow name.
  • The requested permissions match the job’s purpose.
  • New actions, scripts, downloads, and package installs are understood.
  • Secrets, environments, and cloud roles are not exposed to untrusted code.
  • The repository’s branch and workflow policies still apply after approval.

The new hold is most useful when it creates a pause for a real review. Keep that review short for ordinary, expected changes, but do not turn the approval button into another green check that everyone clicks without reading.