GitHub Actions adds three workflow-control features

Short answer

GitHub Actions now provides an API for runner-version deprecation information, a read-only vulnerability-alerts permission for GITHUB_TOKEN, and four job context properties for reusable workflows. The new job properties are not available on GitHub Enterprise Server. No effective date or adoption deadline is stated.

What changed

GitHub says GET /actions/runners/deprecations/{version} is a new REST API available at the repository, organization, or enterprise level. Its response includes runner_version, runtime_deprecates_at, and registration_deprecates_at. Workflows can grant GITHUB_TOKEN the new vulnerability-alerts permission with read or none values for Dependabot alerts. Reusable workflows gain job.workflow_ref, job.workflow_sha, job.workflow_repository, and job.workflow_file_path. These job context values identify the workflow that defines the current job; for reusable workflows, they can differ from the existing github.workflow_ref and github.workflow_sha values. The new job context properties are not available on GitHub Enterprise Server.

Affected product, plan, or suite

GitHub Actions workflows and runner-management APIs; the new reusable-workflow job context properties are unavailable on GitHub Enterprise Server.

Date and timing

Effective date unspecified; announced 2026-09-03

Why now

GitHub published this changelog entry on September 3, 2026, describing three GitHub Actions updates. The runner API reports when registration and runtime support end for a specified runner version. The permission update supports least-privilege access to Dependabot alerts. For jobs defined directly in a workflow, job.workflow_ref matches github.workflow_ref; the source says the values diverge only for reusable workflows. An effective date is unspecified.

Who should care

Self-hosted-runner operators can use the API to plan upgrades before a runner version is deprecated. Security and platform teams whose workflows need Dependabot alert access can evaluate the narrower permission. Reusable-workflow authors can use the new job properties to identify the defining workflow’s ref, commit, repository, and path. GitHub Enterprise Server users should account for the stated lack of support for these new job properties.

Why it matters

The update enables more deliberate runner upgrade planning, narrower token permissions for Dependabot alert access, and clearer source identification inside reusable workflows. These are implementation opportunities rather than a stated migration requirement. Worthd recommends testing the relevant feature in the team’s deployment before changing production workflows.

What this does not change

The source does not state a universal runner cutoff date, an exact cutoff time, rollout timing, availability by plan, API rate limits, or compatibility details beyond the GitHub Enterprise Server limitation for the new job properties. It also does not say that existing workflows must change.

Worthd take

The immediate value is operational rather than a forced migration: make runner support dates visible, reduce token scope where appropriate, and avoid confusing the caller’s workflow identity with the defining reusable workflow. Start with a small permissions test and a runner-version inventory. Treat the Enterprise Server limitation as a compatibility constraint.

What to check next

• Identify self-hosted runner versions and query GET /actions/runners/deprecations/{version} at the repository, organization, or enterprise level used by the team.
• Review workflows that access Dependabot alerts and test vulnerability-alerts: read before reducing broader GITHUB_TOKEN permissions.
• Test the four new job context properties in reusable workflows where the defining workflow’s identity affects behavior.
• If GitHub Enterprise Server is in scope, do not depend on these new job context properties without verifying an alternative.
• Record the deprecation information returned for each relevant runner version and plan upgrades using those dates.