Actions Permissions Check vs. reading the workflow YAML by hand
This page names no company or product — reading a workflow file before trusting it is a habit most maintainers already have, not a competing tool. The gap is not carelessness: permissions inheritance in GitHub Actions is silent by design, and a manual read cannot show what a file does not contain.
What a manual read catches reliably
An obviously missing permissions: block at the top of a short, single-job workflow, or a
permissions: write-all line sitting in plain view near the top of a file. Those are the
cases a reviewer scanning top to bottom notices without much effort, and this tool does not replace that
kind of reading.
What a manual read struggles with, and why
| Case | Reading by hand | This checker |
|---|---|---|
A job with no permissions: key of its own | Silently inherits the workflow-level block, or the repository default if there is none — a reader has to check two other places to know which, and nothing in the file states the repository default at all | Walks the exact inheritance rule for every job and reports the source explicitly: its own grant, or "inherited from the workflow-level permissions" |
| A repository with dozens of workflow files, several jobs each | Checking every job in every file for an override is repetitive and exactly the kind of check attention degrades across | Scans every pasted file identically; job fifty gets the same treatment as job one |
permissions: write-all on one job buried mid-file | Easy to miss once a reader has already judged the workflow-level block near the top to look fine and reads job bodies less closely afterward | Flags it by file and line regardless of where in the file it sits or what came before it |
| Distinguishing an explicit but narrow grant from an explicit but still-broad one | Requires holding "what scopes does this job actually need" in mind while reading unrelated YAML around it | Reports the exact scopes text for every explicit grant, so the narrowing judgment is made against a clean list, not while parsing indentation |
None of this is about attention or diligence. Permissions inheritance is genuinely silent in the file format itself: a job's own missing key is not an error, it is a valid workflow that means something different depending on state the file does not contain.
When to still read the file yourself
This tool only reports whether a permissions: key exists, whether it is
write-all, and what scopes an explicit grant lists. It does not know your repository's or
organization's actual default token permissions — there is no public API for that setting, and it
makes no network call to check. It also does not decide whether the scopes a job does declare are the
minimum that job needs; judging that against what each step in the job actually does is still a job for
reading the workflow yourself.
Common questions
What does reading a workflow file by hand catch reliably?
An obviously missing permissions: block at the top of a short, single-job workflow, or a permissions: write-all line sitting in plain view. Those are the cases a reviewer scanning the file top to bottom is good at noticing, and this tool does not replace that kind of reading.
Why does job-level inheritance make a manual read unreliable across a real repository?
Because a job with no permissions: key of its own silently inherits the workflow-level block, or the repository's ambient default if the workflow has none either -- and nothing in the file tells a reader which case applies without checking two other places first: whether the workflow itself declares permissions:, and, if not, what the repository or organization default is set to (which no workflow file states at all). A reviewer has to hold that inheritance chain in their head correctly for every job in every file; a scanner walks the same chain the same way every time and never loses count partway through a fifty-job file.
Does file count matter, or is this only about complex single files?
Both. A repository with dozens of workflow files each defining several jobs turns a permissions review into checking every job in every file for an override, which is exactly the kind of exhaustive, repetitive check a reviewer's attention is worst at sustaining across many similar-looking blocks. A tool that scans every pasted file the same way does not get less careful on file thirty than it was on file one.
Is write-all always easy to spot by eye?
It is easy to spot when it sits at the top of a short file. It is easy to miss when it appears on one job buried in the middle of a long file with several other jobs around it, especially if a reader has already concluded from the workflow-level block near the top that the file looks fine and stops reading job bodies closely after that.
Does a clean scan from this tool mean my repository's default token permissions are safe?
No. This tool has no API access and does not know your repository's or organization's actual default GITHUB_TOKEN permissions -- there is no public API for that setting. An unspecified finding means the pasted file itself does not make permissions explicit; it does not mean the ambient default it would fall back to is necessarily broad, and a clean, all-explicit result says nothing about whether the scopes that are declared are the minimum each job actually needs.