GitHub Actions 掃描發現 925 個星數最高的公開儲存庫中有 46 個傳入無效輸入

GitHub Actions has a quiet failure mode. If a workflow passes an input the action doesn't declare, the run doesn't fail. The log gets an Unexpected input(s) warning, the step goes green, and the value is ignored, unless the action happens to read undeclared inputs, which few do.

I wanted to know how often that happens in real projects, so I scanned the workflows of the 925 most-starred public repositories on GitHub.

The numbers

Per input, that's rare: about 1 in 900. Per project, it's common: about 1 in 20 of these well-maintained repositories has at least one setting in CI that does nothing.

What they look like

• Typos (20). cached: true for an action whose input is cache. issue-lock-inactive-days where the action expects issue-inactive-days. file where a coverage action now takes files.
• Newer than the pinned version (23). The input exists on the action's main branch, but the workflow pins an older SHA or tag that predates it. One example is include-hidden-files on an actions/upload-artifact pin from before that input existed. The setting will start working the day someone bumps the pin, and not before.
• Gone or never there (70). The pinned version doesn't declare these inputs, and there is no close match. Some of them are intentional: octokit/request-action forwards arbitrary inputs to the GitHub API, so its undeclared inputs do work. Leaving that action out, it's 95 inputs in 44 repositories.

20 findings were re-checked one at a time against the exact action.yml at the exact pinned ref, and all 20 held up. An earlier run reported 622. That was a caching bug in the scanner, which shared local ./path actions between repositories. It's worth saying, because a number that big would have been wrong.

The method, data and scanner are in research/actions-inputs-2026-10.

Check your own repo

The scan uses the GitHub Actions check from proof-of-effect, a small open-source checker. It needs Python 3.9+ and git, nothing else:

git clone https://github.com/awesome-proof-of-effect/proof-of-effect
python3 proof-of-effect/skills/proof-of-effect/scripts/poe.py check --all --repo /path/to/your/repo

--all audits everything already in the repo. Without it, the checker looks only at what changed since HEAD (or since --base origin/main), which is the mode meant for pull requests and coding agents.

Why it exists

The same failure shows up everywhere there is config, and coding agents hit it constantly: they "fix" something by adding a setting the tool quietly ignores. Some examples:

• strict: true at the top level of tsconfig.json instead of inside compilerOptions
• an .eslintrc edit while ESLint runs in flat-config mode
• a [tool.pytest.ini_options] change while pytest actually reads pytest.ini
• an env var without the VITE_ prefix the browser build needs
• a CLI flag the installed version doesn't have

CI is green in every one of these cases.

proof-of-effect asks the tool itself:

• For tsc, ESLint, Jest, Ruff and pytest, it resolves the config with the old and the new version of the changed file and compares the two.
• For GitHub Actions, it checks inputs against action.yml.
• For env vars, it checks the code that reads them.
• For CLI flags, it checks the installed tool's --help.

It ships as a SKILL.md agent skill, so an agent runs it before claiming a fix. It also works as a plain CLI in CI.

Repo: https://github.com/awesome-proof-of-effect/proof-of-effect

AI disclosure: the checker, the scan and this write-up were produced with an AI coding agent working in my repository. Every number above comes from the published scan data, and the checks are tested against the real tools in CI.