Question: Publisher verification path for active code plugin contributors?

[spranab]

Hi team,

I've published several code plugins to ClawHub over the past few days under @spranab / @yantrikos:

• brain (cognitive memory)
• nexus (event bus)
• guardian (security engine)
• conductor (workflow engine)
• quarantine (execution sandbox)
• kubefn (function runtime)
• pageiq (structured web extraction)

All are source-linked, MIT licensed, with tests and documentation.

Two questions:

1. Is there a path to "verified publisher" status for community contributors? Something between the current community channel and official that signals trust to users browsing the catalog.

2. Security scan status — all my code plugins show Scan: pending after 24+ hours. Is the code plugin scanner operational, or is there a different timeline for code plugins vs skills?

Happy to help define the verification process if it's still being built. As one of the first community code plugin publishers, I'd love to contribute to making the ecosystem trustworthy for everyone.

Thanks!

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 17, 2026, 6:09 PM ET / 22:09 UTC.

Summary
Keep open. Current main has official publisher rows, trusted-publisher config, release verification tiers, and package scan queues, but it still does not provide a public verified or vetted-community publisher path; the named pending code-plugin scans require production scanner and queue inspection rather than a source-only close.

Reproducibility: Do we have a high-confidence way to reproduce the issue? No. Source inspection confirms no public verified/vetted-community publisher path on current main, but the pending-scan symptom needs production package records, queued job state, scanner environment, and failure logs for the named plugins.

Root-cause cluster
Relationship: canonical
Canonical: #1301
Summary: This issue is the clearest combined report for community verified-publisher policy plus named pending code-plugin scans; related items overlap with only the policy, badge, evidence-surface, or scanner-health portions.

Members:

• same_root_cause: Trying to get Plugin verified #1994 - Open author-specific request for getting a plugin verified, matching the community verification path question without the named scanner-health details.
• partial_overlap: RFC: Define a public review path for vetted community plugins #2272 - Open RFC covers the broader vetted-community plugin policy decision, but not the named pending scan operational question.
• partial_overlap: feat: add plugin verify evidence endpoint #2411 - Open draft PR proposes a plugin verification evidence endpoint related to trust review, but it is not merged and does not add a vetted-community badge.
• partial_overlap: Feature - Implement paid certificate or badge for a manual review and approval of skills #184 - Open issue asks for a paid human-review certificate or badge for skills, overlapping trust-badge semantics but not this code-plugin publisher/scanner report.
• partial_overlap: pop-pay flagged suspicious — capability-based classification, no malicious code found. Verified publisher path? #1526 - Closed scanner appeal also asked about verified publisher or audited-high-risk classification and was routed to rescan guidance.
• 1 more in the report.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Manual review is required because trust-status semantics and production scanner health are security, product, and operations decisions rather than a narrow source repair.

Security
Needs attention: The issue is security-sensitive because a new verified or vetted status would become a user-facing trust signal for third-party executable plugins.

Review details

Best possible solution:

Use #2272 for the vetted-community policy decision, inspect production scanner state for the named packages, and open a narrower source bug only if queue, config, or worker failure is confirmed.

Do we have a high-confidence way to reproduce the issue?

Do we have a high-confidence way to reproduce the issue? No. Source inspection confirms no public verified/vetted-community publisher path on current main, but the pending-scan symptom needs production package records, queued job state, scanner environment, and failure logs for the named plugins.

Is this the best way to solve the issue?

Is this the best way to solve the issue? No direct source fix is ready. The maintainable path is a maintainer-approved vetted-community policy plus production scanner inspection, with code/docs changes only after trust semantics or a concrete scanner failure are known.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Production packageRelease records, securityScanJobs, scanner environment, worker state, and Convex failure logs for the named plugins were not available from the read-only checkout.
• A verified or vetted-community trust signal could mislead users unless maintainers define review criteria, authority, package-vs-publisher scope, expiry, revocation, and wording before implementation.
• The open plugin verify endpoint proposal is draft and explicitly evidence-only, so it should not be treated as satisfying the requested verified publisher path.

Codex review notes: model internal, reasoning high; reviewed against 3c46a6b9963f.

Label changes

Label changes:

• add issue-rating: 🦐 gold shrimp: Current issue advisory state selects this label.
• remove issue-rating: 🦪 silver shellfish: Current issue advisory state no longer selects this label.

Label justifications:

• P2: This is a meaningful marketplace trust and scanner-health issue with security implications, but it is not a confirmed outage or bypass.
• impact:security: Verified/vetted publisher status and scan state directly affect user trust in installable third-party code plugins.

Evidence reviewed

Security concerns:

• [medium] Define assurance boundaries before verified status
  Maintainers need to define review criteria, grant authority, package-vs-publisher scope, expiry, revocation, and relationship to Official, trustedPublisher, and scan status before users rely on a new trust label.
  Confidence: 0.92

What I checked:

• Repository policy read: AGENTS.md was read fully and applied; it requires durable specs for security-sensitive moderation, scanner, upload-gating, and API trust-boundary behavior, and this ClawHub cleanup pass should only close issues when current main definitely implements the request. (AGENTS.md:1, 3c46a6b9963f)
• Official publisher scope is narrow: Official status is derived from exact ClawHub-managed officialPublishers rows, is not inherited from trustedPublisher or identity state, and has no generic public endpoint for arbitrary publishers. (specs/official-publishers.md:3, 3c46a6b9963f)
• No vetted-community channel in schema: The current package channel validator only allows official, community, and private, while verification tiers are structural, source-linked, provenance-verified, and rebuild-verified. (convex/schema.ts:424, 3c46a6b9963f)
• Verification rollout remains policy-gated: The plugin plan says verification should launch with a small cohort of publisher accounts ClawHub explicitly trusts, and unverified community plugins should not look equivalent to cohort-verified releases. (specs/plans/plugins.md:464, 3c46a6b9963f)
• Package publish starts pending scans: The package publish path initializes non-trusted plugin verification scan status as pending, then schedules VirusTotal and ClawScan work for the release. (convex/packages.ts:6234, 3c46a6b9963f)
• Package ClawScan queue exists: Current main enqueues packageRelease securityScanJobs and deduplicates active queued/running jobs, but this source evidence does not prove the reporter's production jobs completed. (convex/securityScan.ts:2050, 3c46a6b9963f)

Likely related people:

• Patrick-Erichsen: Blame and file history attribute the official publisher policy, package channel/verification schema, package publish scan initialization, ClawScan queueing, and VirusTotal package scan action to Patrick Erichsen. (role: current trust and scanner surface contributor; confidence: high; commits: e3e5705d8969, 911515194911, 3c46a6b9963f; files: specs/official-publishers.md, convex/schema.ts, convex/packages.ts)
• Andy Ye: Recent history shows a focused repair to historical ClawPack release files in convex/packages.ts, adjacent to package scan and release-file health. (role: adjacent package scan repair contributor; confidence: medium; commits: 6d87fc078d89; files: convex/packages.ts)
• Jesse Merhi: Recent package history includes removal of retired moderation surfaces in convex/packages.ts, adjacent to trust and official-publisher semantics that any verified path must keep distinct. (role: adjacent official-policy contributor; confidence: medium; commits: 303075c82b48; files: convex/packages.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Keep open. Current main has code-plugin verification tiers, trust-channel plumbing, trusted-publisher gates, and package scan scheduling, but this issue asks for a maintainer/security policy answer and a production scanner-health check for named published plugins. Source review cannot determine whether these publishers should be verified or why their deployed scan state remained pending.

Required change / next step:

This needs maintainer/security/product judgment plus production Convex scanner inspection before a source fix can be scoped; no narrow code/docs defect is established from the checkout alone.

Review details

Best possible solution:

Maintainers should publicly state whether community verified/trusted publisher status is available, planned, or intentionally unavailable, document the process if it exists, and inspect production scanner health for the named plugins. If that inspection finds a queue, configuration, backfill, or rescan bug, it should be tracked as a narrower source fix.

Acceptance criteria:

• Inspect production packageReleases for brain, nexus, guardian, conductor, quarantine, kubefn, and pageiq, including vtAnalysis, llmAnalysis, staticScan, verification.scanStatus, and scheduled job state.
• Check active deployment scanner configuration for VT_API_KEY and OPENAI_API_KEY / LLM scan availability.
• Review Convex insights and failure logs for package scan jobs and rescan requests.
• If a concrete source bug is found, validate with focused package scan/rescan tests plus bun run lint and relevant typecheck/deploy checks.

What I checked:

• Issue scope: The issue asks two operational/product questions: a verified-publisher path between community and official for @spranab / @yantrikos code plugins, and scan status for brain, nexus, guardian, conductor, quarantine, kubefn, and pageiq after 24+ hours pending. (7bef2a0b65d4)
• Related open policy report: Related pop-pay flagged suspicious — capability-based classification, no malicious code found. Verified publisher path? #1526 is open and asks the same verified-publisher/high-risk-audited question for a sensitive plugin classification, so the policy question is not resolved by source code alone. (7bef2a0b65d4)
• Verification policy is intentionally cohort-based: The plugin plan defines structural, source-linked, provenance-verified, and rebuild-verified tiers, then says initial verification should launch with a small cohort of publisher accounts ClawHub explicitly trusts. (docs/plans/plugins.md:453, 7bef2a0b65d4)
• Official channel is policy-assigned: Trust-channel rules state that channel is assigned by ClawHub policy, official is a moderator-set flag, and official status must not come from package metadata or publisher claims. (docs/plans/plugins.md:518, 7bef2a0b65d4)
• HTTP API documents trusted-publisher gate: The package publish API requires source metadata for code plugins and documents that only trusted publishers may publish to the official channel. (docs/http-api.md:431, 7bef2a0b65d4)
• Publish path initializes pending scan state and schedules scanners: Package publish runs static scanning, initializes verification scanStatus as pending unless static analysis is malicious, inserts the release, then schedules VirusTotal and LLM package scans. (convex/packages.ts:2112, 7bef2a0b65d4)

Likely related people:

• Patrick Erichsen: Git blame and file history attribute the central docs, schema, package publish flow, official-channel validation, VirusTotal package scan action, and API docs to ecf09b8; later plugin curation work in the same area is also by this author. (role: introduced current package registry, verification policy, scanner scheduling, and trusted-publisher surfaces; confidence: high; commits: ecf09b868a98, a7d1701f5a3d, 1d79f78426c0; files: docs/plans/plugins.md, docs/http-api.md, convex/packages.ts)
• Vincent Koc: A recent commit changed idempotent retry behavior in the same package publish path, which is adjacent to publishing reliability but not the core trust policy or scanner implementation. (role: adjacent maintainer for package publish retry behavior; confidence: medium; commits: 064804e2d31b; files: convex/packages.ts)

Remaining risk / open question:

• Production packageRelease records, scheduled jobs, Convex env, and scanner logs for the named plugins were not available from the source checkout and still need maintainer inspection.
• The verified/trusted publisher or high-risk audited classification policy remains unresolved and overlaps with open pop-pay flagged suspicious — capability-based classification, no malicious code found. Verified publisher path? #1526.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 7bef2a0b65d4.