Greptile Summary

This PR introduces a two-phase GitHub Actions workflow for publishing @openclaw/* plugin packages to npm, along with the scripts and metadata changes that drive it. On every push to main, the workflow auto-detects changed plugins, validates metadata, and previews what would be published; the actual publish step only fires on manual workflow_dispatch, which is a good safety gate. The PR also removes the old lockstep version enforcement from release-check.ts, allowing plugins to evolve independently on their own YYYY.M.D versioning cadence.

Key changes:

• .github/workflows/plugin-npm-release.yml: New workflow with preview-only-on-push and publish-on-dispatch pattern. Two run: steps (Preview publish command and Publish) interpolate ${{ matrix.plugin.packageDir }} directly into the shell command string instead of using env vars, which is inconsistent with the Ensure version is not already published step in the same job that correctly uses env:.
• scripts/lib/plugin-npm-release.ts: Core library with solid logic. The parseReleaseVersion re-check on lines 143–150 is unreachable dead code (the same validation already runs in collectPublishablePluginPackageErrors).
• scripts/plugin-npm-release-check.ts / plugin-npm-release-plan.ts: Both scripts contain a byte-for-byte identical parseArgs function; extracting it to the shared lib would reduce duplication.
• Extension package.json files: Correctly mark 12 plugins as publishToNpm: true.
• test/plugin-npm-release.test.ts: Good coverage of all pure functions in the library.

Confidence Score: 4/5

• Safe to merge; no logic errors or blocking issues — only style and minor security-hygiene suggestions.
• The overall design is sound: preview-before-publish, explicit workflow_dispatch gate for actual publishing, null-ref protection for initial pushes, and an unauthenticated npm view check using an empty temporary .npmrc. The only issues are two run: steps that pass packageDir via direct expression interpolation instead of env vars (low-risk given controlled repo context but inconsistent with the same job's own pattern), one block of unreachable dead code, and a duplicated parseArgs function.
• .github/workflows/plugin-npm-release.yml (lines 155–156 and 201–202) — env-var pattern for packageDir should be made consistent before merge.

This is a comment left during a code review.
Path: .github/workflows/plugin-npm-release.yml
Line: 155-156

Comment:
**Use env variable to avoid script injection**

`${{ matrix.plugin.packageDir }}` is interpolated directly into the shell command string. While the value comes from controlled repository code today, GitHub's security guidance recommends always passing expression values through environment variables in `run:` steps to guard against future injection paths.

```suggestion
      - name: Preview publish command
        env:
          PACKAGE_DIR: ${{ matrix.plugin.packageDir }}
        run: bash scripts/plugin-npm-publish.sh --dry-run "${PACKAGE_DIR}"
```

The same pattern applies at line 202 in `publish_plugins_npm`.

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-npm-release.yml
Line: 201-202

Comment:
**Use env variable to avoid script injection**

`${{ matrix.plugin.packageDir }}` is interpolated directly into the shell command. The `Ensure version is not already published` step above this one correctly passes values through `env:`, but this step does not. Consistent use of env vars is the recommended practice.

```suggestion
      - name: Publish
        env:
          PACKAGE_DIR: ${{ matrix.plugin.packageDir }}
        run: bash scripts/plugin-npm-publish.sh --publish "${PACKAGE_DIR}"
```

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

---

This is a comment left during a code review.
Path: scripts/lib/plugin-npm-release.ts
Line: 143-150

Comment:
**Redundant version re-parse (dead code)**

`collectPublishablePluginPackageErrors` on line 137 already validates the version with `parseReleaseVersion` and, if invalid, adds an error that causes the `continue` on line 140 to fire. That means `parsedVersion` can never be `null` here — this block is unreachable and can be simplified:

```suggestion
    const version = packageJson.version!.trim();
    const parsedVersion = parseReleaseVersion(version)!;
```

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

---

This is a comment left during a code review.
Path: scripts/plugin-npm-release-check.ts
Line: 12-52

Comment:
**Duplicated `parseArgs` logic**

The `parseArgs` function here is byte-for-byte identical to the one in `scripts/plugin-npm-release-plan.ts` (lines 6–46). Consider extracting it into `scripts/lib/plugin-npm-release.ts` (e.g. as `parsePluginReleaseArgs`) so both scripts can import and reuse it, reducing maintenance burden.

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

_{Last reviewed commit: ecb092c}

🔒 Aisle Security Analysis

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

1. 🟠 Unpinned GitHub Actions references (tag-based) allow supply-chain compromise

Description

The workflow uses third-party GitHub Actions by mutable tags rather than immutable commit SHAs.

If an upstream action tag is moved or a maintainer account is compromised, the workflow could execute attacker-controlled code in CI, potentially leading to:

• Unauthorized publishing to npm (via the publish_plugins_npm job)
• Exfiltration of CI credentials/OIDC tokens
• Modification of build artifacts

Vulnerable locations (examples):

• actions/checkout@​v6 is used multiple times in this workflow.

Vulnerable code:

- name: Checkout
  uses: actions/checkout@​v6

Recommendation

Pin all third-party actions to an immutable commit SHA (and optionally keep the version comment for readability). Example:

- name: Checkout
  uses: actions/checkout@<COMMIT_SHA> # v4.2.2

Also review indirect action usage via local composite actions (e.g., .github/actions/setup-node-env) and pin those uses: references as well (e.g., actions/setup-node, actions/cache, etc.). Consider enabling Dependabot version updates for GitHub Actions to keep SHAs current.

2. 🔵 Git option/argument injection via unvalidated --base-ref/--head-ref passed to git diff

Description

The plugin NPM release tooling accepts --base-ref and --head-ref from CLI args without validation, and passes them directly as positional arguments to git diff.

Because git diff parses options until it reaches a non-option argument, a ref value that starts with - (e.g., --no-index, --output=..., --patch) can be interpreted as a git diff option rather than a revision. This allows an attacker who can control these arguments to change the behavior of the git invocation (option injection), potentially causing:

• incorrect change detection (release plan/check using the wrong set of changed extensions)
• unexpected filesystem reads/writes depending on the injected git diff option (e.g., --no-index changes semantics to comparing paths; --output=<file> may write output to a file)
• potential information exposure in logs if output mode is changed

Relevant locations:

• argument source: parsePluginReleaseArgs allows arbitrary --base-ref/--head-ref strings with no validation [scripts/lib/plugin-npm-release.ts:94-150]
• sink: execFileSync('git', ['diff', ... baseRef, headRef, '--', 'extensions']) [scripts/lib/plugin-npm-release.ts:298-323]

Vulnerable code:

execFileSync(
  "git",
  ["diff", "--name-only", "--diff-filter=ACMR", baseRef, headRef, "--", "extensions"],
  { cwd: rootDir, encoding: "utf8", stdio: ["ignore", "pipe", "pipe"] },
);

Note: In the provided GitHub workflow, BASE_REF/HEAD_REF appear to be commit SHAs, which reduces exploitability in CI; however, the library/API itself remains vulnerable if invoked with attacker-controlled refs (now or in future automation).

Recommendation

Harden git ref handling to prevent git diff option injection.

Option A (recommended): resolve and validate refs to commit SHAs

1. Reject values that begin with - or contain whitespace/control characters.
2. Resolve to a commit SHA using git rev-parse --verify and pass the resolved SHA to git diff.

Example:

function resolveCommitSha(rootDir: string, ref: string): string {
  if (!ref || /^-/.test(ref) || /\s/.test(ref)) {
    throw new Error(`Invalid git ref: ${JSON.stringify(ref)}`);
  }

  return execFileSync(
    "git",
    ["rev-parse", "--verify", `${ref}^{commit}`],
    { cwd: rootDir, encoding: "utf8", stdio: ["ignore", "pipe", "pipe"] },
  ).trim();
}

const baseSha = resolveCommitSha(rootDir, baseRef);
const headSha = resolveCommitSha(rootDir, headRef);
const changedPaths = execFileSync(
  "git",
  ["diff", "--name-only", "--diff-filter=ACMR", baseSha, headSha, "--", "extensions"],
  { cwd: rootDir, encoding: "utf8", stdio: ["ignore", "pipe", "pipe"] },
).trim().split("\n").filter(Boolean);

Option B: add an explicit end-of-options marker before revisions (and keep a second -- for pathspec), if compatible with your git diff invocation:

["diff", "--name-only", "--diff-filter=ACMR", "--", baseRef, headRef, "--", "extensions"]

Either approach ensures refs cannot be interpreted as options.

3. 🔵 GitHub Actions npm publish runs package lifecycle scripts with OIDC token permission

Description

The plugin NPM release workflow publishes packages using npm publish without disabling lifecycle scripts.

• scripts/plugin-npm-publish.sh constructs and executes npm publish ... --provenance without --ignore-scripts ([scripts/plugin-npm-publish.sh:18-25,42-45]).
• The publishing job grants id-token: write ([.github/workflows/plugin-npm-release.yml:174-182]) and then runs the publish script ([.github/workflows/plugin-npm-release.yml:213-214]).
• If any published plugin package (e.g., under extensions/*) contains lifecycle scripts such as prepublishOnly, prepare, prepack, etc., npm publish may execute them during publish.
• With id-token: write, those scripts can access GitHub Actions OIDC environment variables and attempt to mint/exfiltrate an OIDC token or use it to publish other packages configured for trusted publishing.

Vulnerable code:

publish_cmd=(npm publish --access public --provenance)
...
cd "${package_dir}"
"${publish_cmd[@]}"

Note: the current publishable plugin package.json files in this diff do not define a scripts section, but this workflow design remains brittle and becomes exploitable if scripts are added (intentionally or maliciously) to any publishable plugin package.

Recommendation

Disable lifecycle scripts during publishing, and run any required build steps explicitly.

Option A (recommended): add --ignore-scripts to publish:

publish_cmd=(npm publish --access public --provenance --ignore-scripts)
# and for beta:
publish_cmd=(npm publish --access public --tag beta --provenance --ignore-scripts)

Option B: enforce via env var at the workflow step:

- name: Publish
  env:
    npm_config_ignore_scripts: "true"
  run: bash scripts/plugin-npm-publish.sh --publish "${{ matrix.plugin.packageDir }}"

Additionally:

• Add a CI check to ensure publishable plugin packages do not include lifecycle scripts (fail if package.json.scripts contains pre*publish*, prepare, prepack, etc.).
• Keep the npm-release environment protected (required reviewers) and restrict who can run workflow_dispatch publishes.

Analyzed PR: #47678 at commit 2a46c1f

_{Last updated on: 2026-03-18T13:18:07Z}