If your repository owns a few internal actions or reusable workflows, you have probably had to make an awkward choice: check out the repository just to find those files, or hardcode a repository reference that can drift away from the commit that called it. GitHub has now added a third option. The new self-repository syntax uses $/ to reference actions and reusable workflows from the repository that is already running, at the exact commit for that run. GitHub announced the feature on July 30, 2026 in its Actions changelog.
The new syntax
Put a dollar sign before the path to tell Actions that the target lives in the same repository:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Run the repository action
uses: $/.github/actions/setup-project
- run: npm testThe path is resolved from the repository and commit currently running the workflow. There is no need to check out the repository first just to locate the action. The same form works for a reusable workflow:
jobs:
ci:
uses: $/.github/workflows/reusable-ci.yml
with:
node-version: "22"How it compares with a local path
The older workspace-relative form looks like this:
steps:
- uses: ./.github/actions/setup-projectA ./ reference points at the checked-out workspace. That is still useful when the action needs to read other files from the workspace, but it usually means adding actions/checkout before the action runs. The $/ form identifies the same repository by the commit being executed, so it can be used before checkout or in a job that never needs the source tree.
When to keep checkout
Do not remove checkout just because an internal action now uses $/. Keep it when later steps need source files, generated artifacts, package manifests, or Git history. A common pattern is to use $/ for the internal action, then check out the source only when the job actually needs it.
Why the commit matters
An internal workflow should normally use the same version of its helper action as the workflow that calls it. A hardcoded reference such as org/repository/.github/actions/setup-project@main can change independently, and a version tag can point at code that was not reviewed together with the caller. Self-repository syntax keeps the reference aligned with the caller commit. That makes a workflow run easier to reproduce and makes a change to an internal action travel with the change that uses it.
The changelog also calls out an enterprise policy benefit: repositories that require actions to be pinned to a full-length commit SHA can use this syntax for internal references without inventing a separate release process for every local action.
What is supported
According to GitHub, $/ works anywhere a workspace-relative action path can be used: workflow steps, composite action steps, nested composition, and reusable workflow calls. GitHub's action reference documentation is the place to check the surrounding syntax when you combine it with inputs, secrets, or a reusable workflow interface.
The feature is available on GitHub.com and requires Actions runner version 2.336.0 or newer. If you use self-hosted runners, check the runner version before converting workflows. A workflow that works on GitHub-hosted runners can fail immediately on an older self-hosted fleet because the runner does not understand the new reference form.
Security still matters
Self-repository syntax solves path resolution, not every workflow security problem. Continue to pin third-party actions, keep GITHUB_TOKEN permissions as narrow as possible, and review changes to reusable workflows like application code. GitHub's secure use reference covers the broader controls that still apply.
A practical migration checklist
- Find same-repository action and reusable workflow references that currently use a workspace-relative path or a separately versioned copy.
- Check whether each job needs checkout for source files. Keep checkout where it is needed.
- Upgrade GitHub-hosted or self-hosted runners to version 2.336.0 or newer.
- Convert one internal action or reusable workflow first, then test the workflow from a pull request and from the default branch.
- Document the convention so new internal workflow components use the same-repository form by default.
Common mistakes
The most common mistake is treating $/ as a replacement for checkout everywhere. It is not. It helps Actions find an internal action or workflow, but shell commands still run in the workspace they are given. Another mistake is using the syntax for a different repository. The dollar form is specifically for the repository that owns the current workflow, not for arbitrary dependencies. Finally, check runner support before merging the change, especially if your organization has a mix of hosted and self-hosted runners.
For repositories with a growing set of internal Actions building blocks, $/ is a small syntax change with a useful property: the workflow and the local component stay together at the commit being tested. Use it when you want local composition without a bootstrap checkout, and keep checkout when the rest of the job needs the source tree.