57% of public Claude Code subagents inherit Bash

Out of 216 public Claude Code skills, exactly one passed every check cleanly; out of 87 public subagents, none did. The figures come from Skillcrossroads, a linter for Claude Code artifacts whose author ran it across public repos to see what people actually ship.

At a glance

• The scan covered 216 skills across 18 repos and 123 agents and commands across 10 repos, with caps disclosed, tree SHAs pinned and reproduction commands published for both audits.
• Half the sample of subagents, 50 of 87, ships no tools list at all, so each inherits the caller's whole toolbox including Bash; another 16 grant bare Bash and 8 a wildcard.
• The two reports ran different editions of the same rubric: skills scored with the optional LLM check, agents with deterministic checks only, and the rubric is strict by design.

If you have not been watching the ecosystem, it got big quickly: the catalog site Tons of Skills lists 434 plugins and 2,900 marketplace-visible skills across 19 categories in its snapshot. Broad permissions handed out because they are quick to set up is a familiar pattern; a Microsoft security post from July 16, 2026 calls that kind of scope creep quiet, incremental and rarely revisited.

57% of the subagents declare no tools list

A subagent with no tools list inherits the caller's entire toolbox, Bash included. Leaving the line out reads like a safe default and lands as the opposite: a worker you meant to just read code now carries the grant surface to run shell. Permission prompts still gate execution.

Think of it as a keyring. You asked someone to fetch the mail and handed over every key in the house. The rest of the sample widens the gap: 16 subagents grant bare Bash and 8 grant a wildcard, which puts 85% of the 87 outside least privilege.

Separately, 72 of the 87, or 83%, carry no invocation cue in the description, nothing shaped like "use when" that tells the model when to reach for that agent.

69% of the skills scored have a description that will not reliably fire

Of 215 public skills scored for triggering, 40% are outright unlikely to fire and another 28% are borderline. The author calls "my skill never fires" the number one real-world failure, and it hides in a single frontmatter line.

Secrets are the bright spot: only 6 of the 216 skills tripped the scanner. Triggering is where the sample falls over, and just one skill of the 216 cleared every check.

The sample itself is modest and stated as such: 216 skills from 18 repos, and 123 agents and commands from 10 repos, of which 87 are subagents and 36 are slash commands.

The checks are deterministic, with the LLM pass optional

Most of the checks are pure and deterministic, and each finding ships file:line evidence you can open against the artifact, in the form "SKILL.md:14 links ./references/converter.md, not found". A broken relative link is not a matter of judgement.

The triggering score is the exception. An optional LLM check, which you run with your own key, judges whether a description will actually fire. That is the part behind the 69% figure, and it is also the part that did not run on the agents report.

The CLI is free, npx skillcrossroads ./my-skill, and a GitHub Action gates pull requests. The project is open-core: the public audits are free and the money sits in a hosted Pro tier.

Why does a missing tools line matter if prompts still gate execution?

Claude Code's documentation explains the asymmetry. Bash commands need approval before they run, except for a built-in set of read-only ones, and once you approve with "Yes, and don't ask again" that approval is saved permanently for that repository and command, written to .claude/settings.local.json at the root of the git repo.

The docs add that the saved rule then applies to future sessions anywhere in that repository, subdirectories and worktrees included, and that before version v2.1.211 the rule was saved in the starting directory instead, so an approval granted in a worktree did not carry to the rest of the repo. File edits work differently: a "don't ask again" choice there lasts only until the session ends.

Two caveats the write-up states about itself. The reports ran different editions, skills on rubric v1.2 with the LLM checks and agents on v1.2 deterministic-only, both labeled, so the two sets of percentages are not one measurement. And the rubric is strict on purpose, which in our view is worth holding onto when reading the one-in-216 pass rate: it describes the bar as much as the artifacts.

Re-running the scan yourself

The next useful checkpoint is your own repo rather than someone else's: both audits publish pinned tree SHAs and the commands to reproduce them, so the same rubric can be pointed at your artifacts and the numbers should land in the same place. What the write-up does not give is a date for bringing both reports onto one edition, which is what it would take to compare skill scores and agent scores on equal terms.