Codex review: needs real behavior proof before merge. Reviewed July 16, 2026, 9:35 PM ET / July 17, 2026, 01:35 UTC.

Summary
Adds a 697-line draft RFC defining a plugin-owned external-verification path while retaining OpenClaw ownership of approval state, terminal decisions, auditing, and protected-tool continuation.

Reproducibility: not applicable. this is a design proposal for a new plugin and approval capability, not a report of broken existing behavior. Source and current documentation instead confirm that the proposed external-resolution seam is not implemented today.

Review metrics: 1 noteworthy metric.

• RFC scope: 1 file, 697 lines added. A single document defines a substantial new approval and plugin API contract that warrants focused ownership review.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Attach redacted live proof against the revised registration-derived and attempt-bound contract.
• Obtain explicit approval/API security-owner acceptance of the permanent plugin authority boundary.

Proof guidance:

• [P1] Needs real behavior proof before merge: The revised contract has no after-change live proof; add a redacted terminal capture, logs, linked artifact, or short recording showing allow-once, session trust, denial, external verification, and resumed execution, then update the PR body for automatic re-review or ask a maintainer to comment @clawsweeper re-review; redact keys, IP addresses, phone numbers, private endpoints, and other sensitive data.

Risk before merge

• [P1] Accepting the RFC establishes a compatibility-sensitive plugin API contract; minimum-host registration behavior and legacy-client fail-closed behavior must remain explicit.
• [P1] The proposed verifier can influence whether a protected action resumes, so registration-derived identity, attempt binding, denial precedence, replay behavior, and grant idempotency are security-boundary requirements rather than implementation details.
• [P1] No live artifact demonstrates the revised contract; the older prototype used materially different authority and resolver semantics.

Maintainer options:

1. Require owner review and aligned proof (recommended)
   Keep the RFC draft until an approval-boundary owner accepts the contract and a current prototype proves the proposed registration, legacy-client, denial, and replay behavior.
2. Accept the design with an explicit proof override
   A maintainer may accept the specification before implementation while explicitly owning the unproven compatibility and security assumptions.
3. Pause the core API direction
   Close or defer the RFC if maintainers do not want external verifier attestations to become part of the core plugin contract.

Next step before merge

• [P1] An approval-boundary owner must decide the durable plugin authority and compatibility contract; there is no narrow automated repair to dispatch.

Maintainer decision needed

• Question: Should OpenClaw accept this registration-derived, attempt-bound plugin attestation contract as the permanent core seam for external approval verification?
• Rationale: The RFC deliberately lets plugin code attest an external ceremony that can unblock protected execution; automation cannot choose that durable trust and compatibility boundary.
• Likely owner: kevinslin — They are actively reviewing the exact API, compatibility, and approval semantics that require a human decision.
• Options:
  • Validate and accept the narrow seam (recommended): Keep the revised ownership model, require approval-boundary review plus prototype-aligned proof, and accept the RFC once those checks confirm the contract.
  • Require a prototype before acceptance: Leave the RFC in draft until a current implementation demonstrates the revised identity, compatibility, replay, and denial semantics.
  • Reject external resolution in core: Keep plugin approvals limited to existing decisions and require external verifiers to use a separate plugin-owned workflow without protected-call continuation.

Security
Needs attention: The document adds no executable supply-chain surface, but its proposed verifier authority is a security boundary requiring explicit owner acceptance.

hey @kevinslin, sorry for the delay, i was traveling and just caught up.

rebased this on latest main and tightened it based on your feedback: motivation is now focused on the plugin-owned external verification need, removed the auto-mode/status-card/history noise, clarified that no autoreview change is required, and made the resolver authority explicit (operator.approvals, no operator.admin requirement for external plugin helpers).

would you mind giving it another pass when you have a chance? also happy to move the discussion somewhere else if that would be better.

@clawsweeper re-review

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

this is coming together. lets tighten it and make sure important behavior is specified

• plugin should not be caller provided - this allows claiming any plugin id
• the approval logic should be explicitly spelled out and should be AND (any DENY on approval path should result in DENY)
• older openclaw clients won't be able to support new format and will only show DENY option
  • we should have a min openclaw version and not register plugin if client doesn't support new format
• unless there is a good reason, we should stick with current semantics for approvals (allow-always, allow-session) - this should map on to existing implementation details
• for auditing, we should send when verification started and ended back to openclaw - currently not in the api
• externalResolution.decisions has no default - should specify one (eg. allow-once)

Some callouts from codex:

[P1] Bind cancellation to the originating run. The RFC promises run cancellation defeats late verification, but its immutable context omits runId and never defines the abort-to-approval cancellation path. Current plugin approval requests omit run identity, while Gateway abort handling targets only exec approvals (src/gateway/server-aux-handlers.ts:153). A late proof could therefore win and authorize a reusable grant after the originating run stopped. Add a host-derived run binding, atomic approval/attempt cancellation, and concurrent-run race tests.
[P1] Define identity for replay versus retry. The RFC distinguishes duplicate delivery of one action from an explicit retry, but neither the typed action nor /approve … external … command defines the stable invocation identity used to distinguish them. Current canonical resolution carries only {id, kind, decision} (packages/gateway-protocol/src/schema/approvals.ts:245). Require a host-derived interaction/message ID: duplicate IDs return the existing attempt; explicit retry gets a new ID and cancels the old attempt.
[P2] Give background verifier work a cancellation signal. The plugin starts polling or callback work and returns, but core can subsequently terminate the attempt through retry, denial, expiry, cancellation, competing resolution, or shutdown. State rejection prevents a late allow, but nothing tells the plugin to stop polling or prevents stale progress output. Add an AbortSignal or terminal callback and invalidate the presentation sink.

ClawSweeper status: review started.

I am starting a fresh review of this pull request: docs: propose plugin-owned external verification approvals This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

Thanks for the follow-up @kevinlin-openai! Addressed all three callouts in 4481068, rebased on latest main and refreshed the PR's description, ready for another 👀 when you have a chance!

Implementation of the accepted contract is now ready for review:

• OpenClaw core/runtime/UI/docs: feat(approvals): add external verification contract openclaw#113517
• AgentKit verifier/grant/delegation work: feat: implement external verification approvals Guardiola31337/openclaw-agentkit#2
• Runtime-proof tracker: Expose plugin approval APIs needed by external HITL plugins openclaw#82336

The PRs implement the RFC’s deny-only generic resolution boundary, host-stamped plugin attempt ownership, verifier presentation/completion split, revision-bound retries, first-answer-wins resolution, durable proof-free audit state, lifecycle cancellation, exact session/tool grants, and signed one-use delegation over pinned TLS.

Hosted final-SHA proof:

• https://github.com/openclaw/openclaw/actions/runs/30151713611 — 61 jobs passed; one unrelated TUI timing case failed, passed when isolated locally, and is the sole cause of the red aggregate gate.
• https://github.com/Guardiola31337/openclaw-agentkit/actions/runs/30146256696

The real local Gateway scenarios covered the accepted human and delegation flows. The remaining caveat is that the human World transport was deterministic/mocked rather than a physical World App/manual scan; that limitation is recorded in both PRs and the tracker.