Repository navigation
v0.4.1 #2
soemoescode
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
A repository can make your coding agent run code the moment it opens the folder. GuardSkill checks for that before you do.
npx guardskill .Read-only. No network calls, no telemetry, no configuration, no account, no dependencies. It reads git configuration and hook scripts, prints what it found, and exits.
The problem
Coding agents gather context by running ordinary git commands —
git status,git diff— as soon as they open a project. Git reads its settings from the repository's own.git/config, and roughly two dozen of those settings name a program for git to execute. Put a command incore.fsmonitorand it runs, with your privileges, outside any sandbox, before you have typed anything.Two pieces of public research make this concrete. GitSpawn (Manifold Security) reported eight findings across seven coding agents, and their note on delivery matters: cloning a hostile URL does not trigger it, because
.git/configis not transferred by a clone — the project has to arrive as files with its.gitdirectory already inside, so a zip, a shared drive, a sync folder or an unpacked archive is the vector. CVE-2026-45033 (GitHub Copilot CLI, CVSS 8.5) shows a bare repository hidden anywhere in the tree is enough on its own, because git discovers it while walking directories.The recommended user-side mitigation in both write-ups is the same: inspect the git configuration before you open the directory with an agent. That is tedious by hand across a tree.
What is in 0.4.1
No detection changes. This release exists so the published entry points are what the documentation says they are.
--ignore-scripts, because this action runs in other people's CI and a lifecycle script must never execute.GuardSkillis an existing GitHub username, and the Marketplace requires a name that matches no existing action, user or organisation.versioninput equals this package's version. Forget to bump it and every consumer keeps scanning with the old rules while the listing names the new tag — the same failure shape as the packaging bug closed in 0.4.0, one layer out.docs/, which holds the two independent security reviews this tool was put through and the acceptance gate they were judged against. Both rounds found a blocking defect; both are published unedited.Using it
In CI:
Exit codes:
0nothing at or above the threshold and the whole tree inspected ·1findings at or above it ·2the scan could not run ·3part of the tree was not inspected. An incomplete scan fails unless you pass--allow-incomplete, because "we did not look there" is not the same as "there is nothing there".Verifying what you install
Published from the tag by GitHub Actions with npm provenance, through OIDC — there is no publish credential stored in a repository secret. The package on the registry is traceable to the workflow run and the commit that built it, and you can check that yourself rather than taking it on trust:
What it does not do
Detection stops at git level. Agent settings files, MCP server definitions and npm lifecycle scripts reach the same outcome by a different route and are not covered here — that class is 0.5.0, and unlike the git-level vectors it travels with an ordinary
git clone. Four executing git keys are deliberately out of scope, listed with reasons inrules/git-exec-keys-inventory.md; the accepted residual risks are inSECURITY.md.False positives are the most useful thing you can report: a scanner that cries wolf gets uninstalled, so a report there is worth more than a star. 86 tests, none skipped on Linux, no dependencies, no network, MIT.
This discussion was created from the release v0.4.1.
All reactions