fix(claude-config): apply loadability model to permission-rule-check

[kyle-sexton]

Fixes #2406

Replaces the `vendor/` path-segment exclusion with a documented-path loadability filter:

• Audits `.claude/skills//SKILL.md` (project and nested, including under `node_modules/` or `vendor/`)
• Audits plugin `skills//SKILL.md` and parallel agents/commands paths
• Excludes non-loadable candidates (e.g. `vendor/foo/SKILL.md`, `pkg/skills/foo/SKILL.md`) with disclosed counts

Installed-vs-orphaned plugin-cache filtering (`installed_plugins.json` oracle) remains out of scope per the issue.

Related

N/A

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[claude]

Claude finished @kyle-sexton's task in 3m 37s —— View job

---

Review complete

• Gather context (CLAUDE.md, REVIEW.md, PR diff)
• Understand the request (code review)
• Review changed files for correctness, architecture, error handling, test coverage, maintainability
• Post findings as inline comments
• Post summary

This repo's CLAUDE.md is empty; REVIEW.md scopes this lane to non-security dimensions and confirms .github/workflows/claude-security-review.yml exists, so security is left to that lane (not applicable here anyway — this is a read-only bash detector).

Summary

The PR replaces the blanket vendor/ path exclusion in permission-rule-check.sh with an allowlist-based frontmatter_is_loadable() model, and updates criteria.md/tests accordingly. The intent — don't silently exclude a whole path segment when nested .claude/skills/ under vendor//node_modules/ is actually loadable — is sound, well-documented, and the denominator/reconciliation invariants are preserved correctly.

One correctness issue found (posted inline on permission-rule-check.sh:368-386): the new plugin-path checks (^plugins/[^/]+/skills/…, …/agents/…, …/commands/…) hardcode this monorepo's plugins/<name>/ wrapper directory relative to $ROOT. But this script is documented (in criteria.md and the skill's own SKILL.md) as scanning "the consuming repo" generically — i.e., it's distributed for use against arbitrary target repos. A standalone Claude Code plugin repo (very common shape: .claude-plugin/plugin.json at repo root, skills/<name>/SKILL.md directly under root, no plugins/ wrapper) would have its genuinely-loadable skill/agent/command frontmatter misclassified as non-loadable and silently excluded — the exact "error-tier check goes blind to a live grant" failure this PR is otherwise designed to prevent. The existing P3 scan a few dozen lines below already solves this correctly by deriving the plugin root dynamically from wherever .claude-plugin/plugin.json sits, rather than assuming a fixed plugins/ prefix — the new filter should do the same. No test fixture currently covers a standalone (non-plugins/-wrapped) plugin repo layout, which is how this gap got through.

Everything else — the find-predicate/loop split preserving disclosed exclusion counts, the reconcile_frontmatter invariant, the CHANGELOG/version bump, and the updated criteria.md prose — is consistent and correctly done.

Branch: cursor/permission-loadability-model-63e1

[claude]

Claude finished @kyle-sexton's task in 1m 33s —— View job

---

Security Review

• Gather context (diff, changed files)
• Review permission-rule-check.sh for injection / traversal / logic flaws
• Review criteria.md and test script changes
• Review plugin.json / CHANGELOG.md
• Post findings

No security issues found.

This PR only changes how permission-rule-check.sh (the audit-permission-grants skill's static linter) classifies which frontmatter files are "loadable" — it replaces a vendor/ path-segment denylist with a frontmatter_is_loadable() allowlist of documented skill/agent/command discovery paths (permission-rule-check.sh#L376-L392). The rest of the diff (criteria.md, permission-rule-check.test.sh, plugin.json, CHANGELOG.md) is documentation, tests, and a version bump.

What I checked, given the request's focus areas:

• Injection surfaces: no new eval, command substitution, or dynamically-constructed command strings built from scanned file content. The new frontmatter_is_loadable() only does bash [[ ... =~ ... ]] regex matching on the file's own path string ($rel, derived by stripping $ROOT as a literal prefix, not a regex) — the file's contents are never interpolated into a command. grep -oE calls still use fixed pattern variables ($P1_ERE, $P2_RULE_ERE, etc.), not attacker-influenced strings, matching the pre-existing pattern.
• Trust-boundary / fail-open logic: the change moves from a denylist (*/vendor/* excluded, everything else audited) to an allowlist (only documented load paths audited, everything else excluded). That's the safer direction for an error-tier check — it fails closed rather than assuming a path shape is safe. I didn't find a case where a genuinely loadable path (per the discovery rules cited from the skills docs) would be misclassified as non-loadable and silently skipped; the new test cases (6b–6d) explicitly cover the vendor/direct, nested-under-vendor, and nested-under-node_modules shapes.
• Path handling: no path traversal risk — $ROOT comes from git rev-parse --show-toplevel or an explicit operator-set env var (unchanged in this PR), and the regexes are anchored (^/$) against the relative path, not used to construct a path for a subsequent read/write.
• GitHub Actions / secrets / supply chain: not applicable — no workflow files, dependency pins, or credential handling touched by this PR.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 26fa82d348

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Claude has reviewed this PR 1 time. The lane skips further automatic reviews after 5; deleting this comment resets the count.

[github-actions]

Warning

Automated security review did not complete — this is an infrastructure failure, not a review verdict.

Treat any Claude comment on this PR (including a placeholder like "I'll analyze this and get back to you") as incomplete, not "no findings."

• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/31598623220
• Failure class: other
• Last SDK result: (no execution file was produced)

The check is green on purpose, and it is not evidence. It certifies that a security pass ran, and this one did not complete — but the cause is outside this PR's control, so merging is deliberately left unblocked rather than locking every merge for the length of the outage. Nothing was reviewed at this head. Where this check is required, it is satisfied without that evidence; a human should review security-sensitive changes here before merging.

Re-run the job to retry the review; a new push also retries it only if the caller's pull_request triggers include synchronize (the canonical security caller keeps it). An automatic retry may already have run — it is skipped when a partial review could duplicate comments, or when the failure class needs an operator.

Re-running does NOT help for every class:

• rate-limit that persists across re-runs, or auth — the credential or usage budget needs an operator; retrying will not clear it.
• a run that exhausted its turn budget ("subtype":"error_max_turns" above) will exhaust it again. As the PR author, split the change into smaller PRs; raising --max-turns is a change to the caller workflow, not something you can set on this PR.

[github-actions]

Warning

Automated review did not complete — this is an infrastructure failure, not a review verdict.

Treat any Claude comment on this PR (including a placeholder like "I'll analyze this and get back to you") as incomplete, not "no findings."

• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/31598623379
• Failure class: other
• Last SDK result: (no execution file was produced)

Re-run the job to retry the review. A new push re-triggers this lane only if the caller's pull_request triggers include synchronize (the canonical caller omits it).
An automatic retry may already have run — it is skipped when a partial review could duplicate comments, or when the failure class needs an operator (auth).