Hard-delete or runtimeId migration needed for @apify/apify-openclaw-plugin

[protoss70]

What

The package @apify/apify-openclaw-plugin has its runtimeId locked to
apify on ClawHub, but our plugin id is now apify-openclaw-plugin. Every
new publish is rejected because runtimeId changes aren't allowed.

We can't rename the npm package (it's canonical, has users on npm).

How ClawHub can fix this

Either:

1. Update the runtimeId on the existing entry from apify →
   apify-openclaw-plugin, or
2. Hard-delete the entry so we can re-publish fresh. (Soft-delete via the
   CLI doesn't help — publish then refuses because the name is still
   reserved.)

Package id: rn74fp3a5j45n1qt1qrngzy4rh83m49c

• Repo: https://github.com/apify/apify-openclaw-plugin
• Contact: integrations@apify.com

[clawsweeper]

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

Summary
Keep open: current main has guarded admin repair primitives, but the live Apify package still has runtimeId: apify while the upstream manifest declares apify-openclaw-plugin, and no merged source change or canonical follow-up resolves this package-specific production repair.

Reproducibility: yes. from source and live read-only checks: publishing to an existing code-plugin package with a different runtimeId still fails closed, and the live Apify row still stores the old runtimeId. I did not mutate production data.

Root-cause cluster
Relationship: canonical
Canonical: #2356
Summary: This issue is the canonical remaining Apify package repair case; it shares the runtimeId/package identity repair root cause with prior OpenViking work, but that work did not update this live package row.

Members:

• same_root_cause: Allow safe runtimeId correction for placeholder code-plugin packages #2133 - The closed OpenViking issue described the same code-plugin runtimeId immutability problem for a different live package.
• partial_overlap: fix: add admin package name repair #2289 - The merged repair PR added an admin package-name repair flow for OpenViking but does not expose a runtimeId-only repair through the current admin route or CLI.
• superseded: Allow placeholder runtime ID correction on publish #2213 - This earlier publish-time runtimeId correction PR was closed unmerged after maintainer feedback that the approach was too implicit.

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

Next step
Needs human maintainer/admin handling because live runtimeId/package identity changes require authority, collision verification, and production-operator execution.

Security
Needs attention: The issue needs security-aware admin handling because runtimeId controls executable plugin identity and package reservation state.

Review details

Best possible solution:

Verify the Apify publisher/admin claim, confirm no active package claims apify-openclaw-plugin, then perform an audited admin runtimeId repair or add a narrow admin-facing command that safely exposes the existing internal primitive.

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

Yes, from source and live read-only checks: publishing to an existing code-plugin package with a different runtimeId still fails closed, and the live Apify row still stores the old runtimeId. I did not mutate production data.

Is this the best way to solve the issue?

Unclear until a maintainer chooses the operator path. Current main has the internal audited repair primitive, so the safest immediate fix may be a maintainer-run production repair; a narrow admin command is the maintainable follow-up if this pattern keeps recurring.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Changing a live code-plugin runtimeId or hard-deleting/recreating the package affects executable plugin identity and package reservation state, so it needs admin authorization, collision checks, and auditability before any production action.

Codex review notes: model internal, reasoning high; reviewed against 22d3cd133cb6.

Label changes

Label changes:

• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: The issue blocks one publisher’s package updates but has limited blast radius and an existing admin-repair shape.
• impact:security: The requested action changes executable plugin identity/reservation state and must preserve authorization, collision checks, and audit logs.

Evidence reviewed

Security concerns:

• [medium] Treat runtimeId repair as identity-sensitive — convex/packages.ts:7460
  Repairing this row should remain admin-authorized, collision-checked, and audited because it changes the executable plugin identity associated with a public package.
  Confidence: 0.9

What I checked:

• Live package still has old runtimeId: The public ClawHub package detail for @apify/apify-openclaw-plugin returns package id rn74fp3a5j45n1qt1qrngzy4rh83m49c with runtimeId: apify, matching the unresolved report.
• Upstream manifest declares the desired runtimeId: The upstream apify/apify-openclaw-plugin manifest on main declares id: apify-openclaw-plugin, so the live ClawHub row and upstream plugin id still diverge.
• Current publish path still rejects runtimeId changes: Existing code-plugin publishes still throw when an existing package has a different stored runtimeId than the incoming release. (convex/packages.ts:8159, 22d3cd133cb6)
• Current main has an internal repair primitive: repairPackageIdentityInternal can patch nextRuntimeId with admin authorization, active runtimeId collision checks, digest update, and audit logging. (convex/packages.ts:7423, 22d3cd133cb6)
• Admin-facing repair route does not expose runtimeId repair: The HTTP repair-name route accepts nextName, retireTarget, optional owner, reason, and dry-run; when applying it calls the internal repair mutation with nextName, not nextRuntimeId. (convex/httpApiV1/packagesV1.ts:2473, 22d3cd133cb6)
• Related OpenViking repair was package-specific: The closed OpenViking issue confirms the same class of runtimeId immutability problem was resolved by a one-off admin repair, but that discussion and merged repair flow do not show the Apify row being fixed.

Likely related people:

• Patrick-Erichsen: Authored the merged admin package-name repair flow for the related OpenViking production repair and has recent adjacent package ownership/security work in this path. (role: recent area contributor and prior repair operator; confidence: high; commits: 636750fbf826, 57c0d860341f, 893f341bdb02; files: convex/packages.ts, convex/httpApiV1/packagesV1.ts, packages/clawhub-admin/src/commands/packages.ts)
• Peter Steinberger: Introduced native package/plugin registry flows, the code-plugin runtimeId freeze, and an earlier package identity repair admin path in the central package files. (role: feature introducer; confidence: high; commits: fc7d4dadca25, 2ace8f9ab48d, 48e66714ac23; files: convex/packages.ts, convex/packages.public.test.ts, convex/schema.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.

[protoss70]

Btw I am the admin of Apify plugin. Just letting you know

[github-actions]

This issue has been automatically marked as stale due to inactivity.
Please add updated ClawHub details or it will be closed.