ACTIONS SECRETS: INHERIT CHECK · RUNS IN YOUR BROWSER

Does secrets: inherit hand your secrets to the wrong workflow?

secrets: inherit on a reusable-workflow call passes every secret your workflow can see to the called workflow — not just the ones it needs. That is fine when the called workflow lives in the same repository you already review. It is a much bigger bet when it lives in another repository, or when the job that inherits it can be triggered by a stranger's fork. Paste your workflow YAML below and this page finds both patterns, each with the exact fix.

Nothing is uploaded. The YAML you paste is read in this browser and never leaves your device, and this tool makes no network calls of its own.

1. Paste one or more workflow files

Copy the contents of each file under .github/workflows/ you want checked. Add more blocks for more files — nothing here reads your repository, so pasting is how it sees anything.

Paste at least one workflow file above and click Check.

Prefer a CLI, or want this in your own CI?

Same logic, zero dependencies, one file:

python3 check.py                  # scan .github/workflows under the current directory
python3 check.py /path/to/repo    # scan a specific checkout
python3 check.py --format json    # machine-readable
python3 check.py --fail-on-risk   # exit 2 if any finding exists

Get check.py from the repo — stdlib only, nothing to install, no network calls. Wire --fail-on-risk into your own CI to block a newly-added finding before it merges.

Common questions

What does secrets: inherit actually do?

On a reusable-workflow call (uses: OWNER/REPO/.github/workflows/file.yml@ref), secrets: inherit passes every secret the calling workflow can see to the called workflow — not just the ones it needs. GitHub's own documentation flags this as something to use with caution, especially when you do not control the called repository.

Why does it matter if the reusable workflow is in another repository?

A local reusable workflow (uses: ./.github/workflows/file.yml) lives in the same repository and the same review process as everything else. An external one (uses: OWNER/REPO/.github/workflows/file.yml@ref) is code you do not review on the same schedule — a compromised account, a force-pushed branch, or simply a maintainer decision at that other repository becomes a way to walk off with every secret you inherited to it.

Why does the trigger matter?

pull_request_target and workflow_run jobs run with the base repository's context even though a stranger's fork raised the event. secrets: inherit on such a job hands the fork-reachable run every secret the workflow can see, rather than the handful a job like "comment on the PR" actually needs.

Does this tool fetch anything from GitHub for me?

No. It makes no network calls at all — nothing here can, because nothing here talks to a server. Paste your workflow YAML and the scan runs entirely in this page.

Does a clean scan mean my workflows are safe?

No. This checks two specific, well-documented patterns in a single workflow file at a time. It is not a security audit and makes no claim about your repository's overall security. It does not evaluate whether the called workflow is actually trustworthy, and it does not follow a local reusable workflow to see what it in turn calls.

More: what is secrets: inherit and when is it risky? · already run zizmor? see what its secrets-inherit audit does and does not check · reviewing workflows by hand instead? see where that holds up and where it slips.