Security scan for open claw plugin

[jaunty tapir]

I published openclaw-plugin-x@0.2.1 with clearer credential/persistence metadata, but the package page still shows scanner concerns around install mechanism and credential declaration.
Two questions:

1. Is there a way to manually retrigger the package security/LLM scan for a published package?

2. For code-plugin packages published via clawhub package publish, should the scanner/UI infer install/runtime behavior from package.json + openclaw.plugin.json, rather than flagging “No install spec / instruction-only.

https://clawhub.ai/plugins/openclaw-plugin-x

[lapis pivot]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[heady wave]

Let me check the docs/source quickly so I don't guess.

I found the package metadata API, and your package is still reporting scanStatus: "pending" on ClawHub right now. I'm checking whether there's any documented/manual re-run path versus this just being a backlog/pipeline issue.

I checked the docs/source plus the live ClawHub package API for your package.

1. Manual retrigger

   • I do not see a documented/public way to manually re-run the package scan from clawhub CLI or the docs.
   • Your package currently still shows scanStatus: "pending" in the API, so this looks more like a ClawHub-side scan pipeline/backlog issue than missing metadata on your side.
   • If it stays stuck, I’d file it on GitHub with the package URL + API output: https://github.com/openclaw/clawhub/issues

2. Should code-plugin behavior be inferred?

   • Yes, I think so.
   • The docs already treat ClawHub plugin packages as installable via openclaw plugins install clawhub:<pkg>, and clawhub package publish expects plugin metadata from package.json plus openclaw.plugin.json, not a separate skill-style install spec.
   • Also, ClawHub is already inferring a bunch from your package today. The live API for openclaw-plugin-x shows:
     • family: "code-plugin"
     • runtimeId: "openclaw-plugin-x"
     • parsed compatibility block
   • So the remaining “No install spec / instruction-only” warning looks like a UI/scanner normalization gap, not that your package failed to declare itself as a real code plugin.

Relevant docs:

• https://docs.openclaw.ai/tools/clawhub
• https://docs.openclaw.ai/plugins/manifest
• https://docs.openclaw.ai/plugins/sdk-setup

Small extra clue: the ClawHub changelog recently mentioned fixes around pending scan starvation / retrying unresolved results, so this may already be on their radar.

If you want, I can help draft a tight GitHub issue for this.

[jaunty tapir]

Yes please

[heady wave]

Yep, here’s a draft you can paste into https://github.com/openclaw/clawhub/issues/new.

Title

Packages: code-plugin scan stays pending / still flags "instruction-only" after publish metadata update

Body

## Summary

I published `openclaw-plugin-x@0.2.1` with clearer credential/persistence metadata, but the ClawHub package page still shows scanner concerns around install mechanism and credential declaration.

I have two related questions:

1. Is there a public/manual way to retrigger the package security/LLM scan for an already-published package?

2. For `code-plugin` packages published via `clawhub package publish`, should the scanner/UI infer install/runtime behavior from `package.json` + `openclaw.plugin.json`, instead of flagging the package as effectively "instruction-only" / "no install spec"?

## Package

- Package page: https://clawhub.ai/plugins/openclaw-plugin-x
- Package API: https://clawhub.ai/api/v1/packages/openclaw-plugin-x
- Version API: https://clawhub.ai/api/v1/packages/openclaw-plugin-x/versions/0.2.1

## What I’m seeing

At the time of writing, the package API already shows ClawHub successfully inferring core package/plugin metadata, including:

- `family: "code-plugin"`
- `runtimeId: "openclaw-plugin-x"`
- parsed compatibility metadata

- `latestVersion: "0.2.1"`

But the package page still shows scanner concerns around install mechanism / credential declaration, and the package detail currently reports a pending scan state.

## Expected behavior

For a `code-plugin` published through `clawhub package publish`, I would expect ClawHub to treat it as an installable plugin package based on normalized package metadata, including:

- `package.json` `openclaw.*` metadata
- `openclaw.plugin.json`
- package family = `code-plugin`

Specifically, I would expect the scanner/UI to infer that this is a ClawHub-installable native plugin, rather than flagging it as "instruction-only" because it does not have a separate skill-style install spec.

## Actual behavior

- The package page still shows scanner concerns after publishing `0.2.1`
- I cannot find a documented/public way to manually retrigger the package scan
- The API suggests the package has already been classified correctly as a `code-plugin`, so this looks like a scanner/UI normalization gap or a stuck/pending scan pipeline

## Repro

1. Publish a native plugin package via:
   ```bash
   clawhub package publish <source>

2. Ensure the package includes:
   • package.json with openclaw plugin metadata
   • openclaw.plugin.json
3. Open the package page on ClawHub

4. Observe that scanner concerns still mention missing install/runtime declaration even though the package is a `code-plugin`

## Questions

- Is there currently any supported manual scan retrigger for published packages?
- If not, should a new version publish automatically force a fresh scan/re-evaluation?
- Should the scanner/UI special-case `code-plugin` packages so they inherit install/runtime semantics from the package family + plugin manifests instead of requiring a separate install spec?

## Environment

- `clawhub` CLI version: <!-- fill in -->
- Publish command used: `clawhub package publish ...` <!-- fill in exact command if useful -->

If you want, I can also tighten this into a shorter maintainer-style version.

[jaunty tapir]

Can you raise the issue