Best possible solution:

Preserve the useful adversarial cases and design notes, then sponsor one narrowly scoped successor that reuses the existing typed hook system and adds only the authenticated caller facts demonstrably absent from that hook; require fresh-install and upgrade proof before any new permanent API or fail-closed setting is accepted.

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

Not applicable: this PR is an exploratory security-feature prototype, not a report of an existing reproducible defect. The branch includes adversarial tests, but its author does not claim integrated live proof or a merge-ready behavior path.

Is this the best way to solve the issue?

No: the author’s own successor plan and current plugin guidance favor a small typed-hook solution with only the authenticated caller context proven necessary, rather than a new cross-runtime policy subsystem and fail-closed configuration family.

AGENTS.md: found and applied where relevant.

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

Label changes:

• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: This protected maintainer draft explicitly says it is not a landing candidate and does not request merge; its reported exploratory tests are therefore not evaluated as merge-gate proof.
• remove rating: 🦪 silver shellfish: Current PR rating is rating: 🦐 gold shrimp, so this older rating label is no longer current.
• remove status: 📣 needs proof: Current PR status label is status: ⏳ waiting on author.

Label justifications:

• P2: This is a substantial security and product-direction prototype, but it is explicitly non-landing and does not report an active user-facing emergency.
• merge-risk: 🚨 compatibility: The draft adds a public plugin API and required-policy configuration that can alter existing plugin and upgrade behavior.
• merge-risk: 🚨 security-boundary: It introduces caller-aware deny policies and authority propagation at side-effect boundaries, so an incomplete contract could weaken or misapply authorization.
• merge-risk: 🚨 availability: Required policy pins are designed to fail closed and could deny normal tools, commands, or message actions when activation or registration fails.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: This protected maintainer draft explicitly says it is not a landing candidate and does not request merge; its reported exploratory tests are therefore not evaluated as merge-gate proof.

Security concerns:

• [high] Resolve the permanent fail-closed policy contract first — src/plugins/plugin-api.types.ts:196
  The draft makes plugin registration and handler availability capable of denying tools, commands, and message actions. That is an intentional security boundary, but its upgrade behavior, supported principals, and owner scope need a maintainer-approved contract before code is split out.
  Confidence: 0.95
• [medium] Avoid a parallel authorization surface without a seam comparison — src/plugins/registry-api.ts:266
  Current OpenClaw guidance already presents typed hooks as the preferred policy and tool-control extension point. Adding a separate authorization API without proving that hooks lack a necessary authenticated-context or final-enforcement seam risks conflicting security behavior.
  Confidence: 0.87

What I checked:

• Explicit non-landing intent: The PR body says this is an experimental archive, explicitly requests no landing or merge, identifies the scope as hundreds of files plus a new authorization subsystem, and describes a separate minimal hook-based successor. (14a57dd06f1e)
• Current extension seam: Current plugin documentation says typed runtime hooks through api.on(...) are the preferred surface for middleware, policy, message rewriting, prompt shaping, and tool control; this supports evaluating a narrow hook-based successor before introducing a parallel authorization API. Public docs: docs/tools/plugin.md. (docs/tools/plugin.md, b79c141fc702)
• Policy-compatible scope guardrail: VISION.md prioritizes security and safe defaults, asks for one focused PR per topic, applies exceptional review to PRs above roughly 5,000 lines, and prefers plugin API extensions over one-off core behavior when a plugin cannot otherwise implement the need. (VISION.md, b79c141fc702)
• New public and operator surfaces: The branch adds api.authorization.registerPolicy(...), manifest authorization-policy declarations, and plugins.entries..authorization.requiredPolicies with fail-closed operation pins; these are compatibility- and security-sensitive product contracts rather than a local implementation detail. (src/plugins/plugin-api.types.ts:196, 14a57dd06f1e)
• Related work is only partial overlap: The related reports cover enriched before_tool_call context, persistent external-content tainting, and a general external guardrail interface. They overlap the motivation but do not establish one merged or proof-positive canonical replacement for this prototype.

Likely related people:

• steipete: Authored both commits, assigned the draft to themself, renamed it to state the non-landing intent, and the PR body names the narrower successor direction. (role: project owner and prototype author; confidence: high; commits: e670d6d97bbd, 14a57dd06f1e; files: src/plugins/plugin-api.types.ts, src/plugins/turn-authority.ts, extensions/codex/src/app-server/run-attempt-runtime.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• 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.

• reviewed 2026-07-10T16:19:43.354Z sha 66e90d7 :: needs real behavior proof before merge. :: none