🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

permissions:
  contents: read
  id-token: write
...
- name: Checkout ClawHub CLI source
  uses: actions/checkout@​v6
  with:
    repository: ${{ env.CLAWHUB_REPOSITORY }}
    ref: ${{ env.CLAWHUB_REF }}
...
- name: Bootstrap ClawHub CLI
  run: |
    exec bun "$GITHUB_WORKSPACE/clawhub-source/packages/clawdhub/src/cli.ts" "$@"

env:
  CLAWHUB_REPOSITORY: openclaw/clawhub
  CLAWHUB_REF: <FULL_COMMIT_SHA>

- name: Checkout ClawHub CLI source
  uses: actions/checkout@​v6
  with:
    repository: ${{ env.CLAWHUB_REPOSITORY }}
    ref: ${{ env.CLAWHUB_REF }}
    path: clawhub-source
    fetch-depth: 1

uses: actions/checkout@<pinned_sha>

- name: Checkout ClawHub CLI source
  uses: actions/checkout@​v6
  with:
    repository: ${{ env.CLAWHUB_REPOSITORY }}
    ref: ${{ env.CLAWHUB_REF }}
    path: clawhub-source

- name: Install ClawHub CLI dependencies
  working-directory: clawhub-source
  run: bun install --frozen-lockfile

- name: Install ClawHub CLI dependencies (no scripts)
  working-directory: clawhub-source
  run: bun install --frozen-lockfile --ignore-scripts

env:
  CLAWHUB_REF: "<pinned-commit-sha>"

Analyzed PR: #59179 at commit fea4c0a

_{Last updated on: 2026-04-01T19:16:17Z}

Latest run failed. Keeping previous successful results. Trace ID: 019d4d52af4156b1b97a1a32589d6bbf.

_{Last updated on: 2026-04-02T09:08:40Z}

Greptile Summary

This PR introduces a complete ClawHub plugin registry release pipeline: a GitHub Actions workflow (plugin-clawhub-release.yml), a planner/checker library (scripts/lib/plugin-clawhub-release.ts), a publish shell script, and opt-in metadata for all current bundled extensions. The new workflow previews on every push to main (using a dry-run) and performs real publishes only on manual workflow_dispatch backed by a protected clawhub-release environment and GitHub OIDC, which is a solid security model.

Key highlights:

• The SHA-pinning check (GITHUB_SHA vs inputs.ref) correctly ensures OIDC tokens cannot be issued for arbitrary commits, providing a strong supply-chain guarantee.
• The version-gate logic correctly skips the version-bump requirement for first-time opt-ins and handles null git refs (initial push) safely.
• PACKAGE_NAME and PACKAGE_VERSION in the pre-publish guard are correctly passed via env vars, following GitHub's injection-prevention guidance — the same pattern should be extended to matrix.plugin.packageDir in the two plugin-clawhub-publish.sh invocations (currently interpolated directly into the run block).
• The "Ensure version is not already published" shell guard only matches HTTP 200, while the TypeScript counterpart uses response.ok (all 2xx); these should be kept consistent.

Confidence Score: 5/5

• Safe to merge; all open findings are minor style/consistency suggestions that don't affect correctness in the expected deployment paths.
• Both findings are P2: one is a best-practice recommendation about using env vars for matrix context values (low practical risk since packageDir is repo-controlled), and the other is an inconsistency between the shell 200-only check and the TypeScript response.ok check (unlikely to matter for a standard GET endpoint). No P0/P1 issues were found. The core OIDC security model, version-gate logic, and SHA-pinning checks are all correctly implemented.
• .github/workflows/plugin-clawhub-release.yml — the two plugin-clawhub-publish.sh invocations (lines 200 and 269) and the HTTP status guard (lines 254–261) are worth a quick look before merge.

This is a comment left during a code review.
Path: .github/workflows/plugin-clawhub-release.yml
Line: 200

Comment:
**Direct context interpolation of matrix value into shell**

`${{ matrix.plugin.packageDir }}` is interpolated directly into the `run` block, which is against GitHub's [security hardening guidance](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-variable) for untrusted context values. While `packageDir` is derived from the repository's own `extensions/` directory names (low practical risk), the same pattern repeated at line 269 (in the real publish step) should be addressed to follow best practices.

The recommended fix is to pass it through an environment variable so the shell receives it as an already-evaluated string rather than an inline expression:

```suggestion
        env:
          CLAWHUB_REGISTRY: ${{ env.CLAWHUB_REGISTRY }}
          SOURCE_REPO: ${{ github.repository }}
          SOURCE_COMMIT: ${{ needs.preview_plugins_clawhub.outputs.ref_sha }}
          SOURCE_REF: ${{ github.ref }}
          PACKAGE_DIR: ${{ matrix.plugin.packageDir }}
        run: bash scripts/plugin-clawhub-publish.sh --dry-run "${PACKAGE_DIR}"
```

The same change should be applied to the `Publish` step at line 269.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: .github/workflows/plugin-clawhub-release.yml
Line: 254-261

Comment:
**Already-published guard only checks HTTP 200, not all 2xx**

The guard only treats `200` as "already published" and treats any other non-`404` status as an unexpected error that aborts. Meanwhile `isPluginVersionPublishedOnClawHub` in `scripts/lib/plugin-clawhub-release.ts` uses `response.ok` (all 2xx statuses) for the same semantic. If ClawHub's API ever returns a `201` or `204` for an existing package (e.g., after a format migration), this shell guard would abort with "Unexpected ClawHub response" instead of the intended idempotency error, and the mismatch between the two code paths could cause confusing failures.

Consider aligning the check with the TypeScript logic:

```suggestion
          if [[ "${status}" =~ ^2 ]]; then
            echo "${PACKAGE_NAME}@${PACKAGE_VERSION} is already published on ClawHub."
            exit 1
          fi
          if [[ "${status}" != "404" ]]; then
            echo "Unexpected ClawHub response (${status}) for ${PACKAGE_NAME}@${PACKAGE_VERSION}."
            exit 1
          fi
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "CI: add ClawHub plugin release workflow" | Re-trigger Greptile}

Follow-up on the bot summary comments:

• PACKAGE_DIR now goes through an env var in both preview and publish.
• The already-published guard now treats any 2xx as published, matching the TypeScript helper.
• The workflow trigger list now also covers the local setup action and the shared npm release helper paths.

One remaining caveat from the Aisle comment is real: this workflow still checks out openclaw/clawhub from a mutable ref. I did not pin that to the current ClawHub PR branch commit because that would be brittle before the paired ClawHub PR lands. Before landing this OpenClaw PR, CLAWHUB_REF should be switched to an immutable ClawHub commit or release artifact.

Final maintainer note:

What changed

• ClawHub plugin release preview/publish now covers shared-input changes correctly, including the local setup action path by prefix;
• the workflow no longer shells matrix.plugin.packageDir directly and the already-published guard now treats any 2xx as published;
• push-path coverage now includes the shared helper files the workflow actually depends on.

Local validation

• pnpm test -- test/plugin-clawhub-release.test.ts
• pnpm release:plugins:clawhub:check -- --base-ref origin/main --head-ref HEAD
• pnpm release:plugins:clawhub:plan -- --base-ref origin/main --head-ref HEAD
• ruby -e 'require "yaml"; YAML.load_file(".github/workflows/plugin-clawhub-release.yml")'
• PATH="$tmpdir:$PATH" PACKAGE_TAG=beta SOURCE_REPO=openclaw/openclaw SOURCE_COMMIT=$(git rev-parse HEAD) SOURCE_REF=refs/heads/onur/clawhub-oidc-plugin-publish bash scripts/plugin-clawhub-publish.sh --dry-run extensions/discord (run earlier against the source-backed ClawHub wrapper)

Notes

• All inline review threads are resolved on the latest head.
• The only remaining design caveat is the mutable CLAWHUB_REF: before landing this PR, it should point to an immutable ClawHub commit or release artifact after the paired ClawHub PR lands.
• GitHub checks are green except install-smoke, which is still actively running on the latest head at the time of this comment.

Follow-up is done.

Latest fix:

• pinned CLAWHUB_REF to reviewed commit 0cb0db9786be074aa820e5dd330cd1142158b62d so the workflow no longer runs ClawHub from a moving branch ref

Validation:

• pnpm release:plugins:clawhub:check -- --base-ref origin/main --head-ref HEAD
• pnpm release:plugins:clawhub:plan -- --base-ref origin/main --head-ref HEAD
• ruby -e 'require "yaml"; YAML.load_file(".github/workflows/plugin-clawhub-release.yml")'
• earlier dry-run smoke of bash scripts/plugin-clawhub-publish.sh --dry-run extensions/discord using the checked-out ClawHub source and explicit PACKAGE_TAG / SOURCE_REPO / SOURCE_COMMIT / SOURCE_REF
• pnpm test -- test/plugin-clawhub-release.test.ts still fails locally before Vitest starts because the local pnpm wrapper at /Users/onur/Library/pnpm/.tools/@pnpm+macos-arm64/10.32.1/node_modules/@pnpm/macos-arm64/pnpm throws SyntaxError: Invalid or unexpected token
• codex review --base main followed by replying to and resolving the resulting PR threads

Current PR state:

• all PR checks are green
• unresolved review threads: 0