feat: add external plugin approval verification by Guardiola31337 · Pull Request #82434 · openclaw/openclaw

Guardiola31337 · 2026-05-16T04:18:37Z

Summary

This is the narrowed AgentKit host API slice after @kevinslin's feedback about avoiding a broad custom-action surface.

Adds externalResolution for plugin approvals as a single command-template field, not arbitrary custom action arrays.
Keeps core as the approval owner: OpenClaw owns pending state, deny, timeout, history, and continuation.
Adds plugin.approval.resolveVerified for proof-backed allow resolution after external verification succeeds.
Uses operator.approvals as the resolver authority; operator.admin still satisfies it as the normal operator-scope superset.
Treats pluginId as the pending approval owner selector, not an authenticated plugin principal.
Teaches approval view models, text/channel renderers, Control UI parsing, protocol schema, SDK types, and TUI selection to carry/render the narrow external verification command.
Rejects mixed normal allow decisions with external verification, so allow-once/allow-always must go through the verified resolver.

This replaces the earlier broader approach from #82431. The chat/status-card follow-up from #82471 is not required for the current AgentKit end-to-end path.

Review context

Design RFC: openclaw/rfcs#15

Tracking issue: #82336

Concrete plugin use case:

AgentKit needs to let a user complete external World verification before a protected OpenClaw tool continues, while keeping OpenClaw core as the approval owner.

flowchart LR
  A[Agent calls protected tool] --> B[OpenClaw creates plugin approval]
  B --> C[OpenClaw renders approval prompt]
  C --> D[User chooses external verification command]
  D --> E[AgentKit starts World verification]
  E --> F[World proof succeeds]
  F --> G[AgentKit calls resolveVerified]
  G --> H[OpenClaw checks approval owner and decision]
  H --> I[Tool call continues]

Trust boundary

flowchart TB
  subgraph Core[OpenClaw core]
    A[Owns pending approval]
    B[Owns deny and timeout handling]
    C[Validates approval id]
    D[Checks pending approval pluginId]
    E[Checks decision came from externalResolution]
    F[Resolves approval and resumes tool]
  end

  subgraph Plugin[AgentKit plugin]
    G[Owns World verification]
    H[Shows QR/link]
    I[Submits proof-backed allow]
  end

  A --> G
  I --> D
  D --> E
  E --> F

Why this shape

The earlier approach exposed arbitrary actions, which made every approval-capable client understand plugin-defined buttons. That was too broad for this use case.

This PR keeps the core approval contract intact and adds only:

externalResolution: one verifier label plus command templates for external verification.
plugin.approval.resolveVerified: an ownership-checked resolver so plugin X can resolve only approvals created by plugin X, and only for decisions exposed by that approval's externalResolution.
TUI selection for the existing command route so the user can choose Verify once, Verify and trust for session, or Deny without typing slash commands.

It does not add arbitrary approval actions, does not require durable status cards, does not require chat.inject, and does not add a broad plugin-admin helper.

Verification

Latest refresh after rebasing on origin/main (2720ac06b7) and addressing CI failures:

/Users/pabloguardiola/.cache/codex-runtimes/codex-primary-runtime/dependencies/node/bin/node scripts/run-vitest.mjs src/plugins/contracts/session-actions.contract.test.ts src/gateway/server-methods/plugin-approval.test.ts src/tui/tui-plugin-approval-selector.test.ts src/tui/tui-event-handlers.test.ts src/tui/tui-command-handlers.test.ts src/tui/components/chat-log.test.ts
- contract shard: 1 file, 11 tests passed
- gateway shard: 2 files, 78 tests passed
- TUI shard: 4 files, 176 tests passed
PATH="/Users/pabloguardiola/.cache/codex-runtimes/codex-primary-runtime/dependencies/node/bin:/Users/pabloguardiola/.cache/codex-runtimes/codex-primary-runtime/dependencies/bin:$PATH" pnpm check:test-types
/Users/pabloguardiola/.cache/codex-runtimes/codex-primary-runtime/dependencies/node/bin/node scripts/docs-list.js
git diff --check

Earlier companion plugin proof against this host API branch:

pnpm test:hitl
pnpm test:openclaw-hitl
pnpm test:local-full-e2e -- --openclaw ../openclaw --skip-host-build --skip-link
pnpm pack:check

Real behavior proof

Behavior addressed: external HITL plugins can ask OpenClaw to show a narrow verification command for allow decisions while core keeps denial and pending approval ownership.

Real environment tested: local OpenClaw checkout with focused gateway/plugin approval tests, TUI selector/event tests, docs listing, test typecheck, and a companion AgentKit plugin gateway e2e run against this host API.

Exact steps or command run after this patch: ran the latest refresh commands listed above after rebasing on current origin/main; earlier AgentKit wrapper proof was run against the linked host API branch and is preserved below.

Evidence after fix: copied after-fix output from the AgentKit local OpenClaw gateway e2e run:

{
  "ok": true,
  "denyApprovalCommands": [
    "/agentkit approve plugin:5f073ff9-7ca7-45ba-bf57-d920909973ea allow-once",
    "/agentkit approve plugin:5f073ff9-7ca7-45ba-bf57-d920909973ea allow-always",
    "/approve plugin:5f073ff9-7ca7-45ba-bf57-d920909973ea deny"
  ],
  "deniedHookResult": {
    "blocked": true,
    "kind": "failure",
    "deniedReason": "plugin-approval",
    "reason": "Denied by user",
    "params": {
      "cmd": "echo agentkit"
    }
  },
  "allowApprovalCommands": [
    "/agentkit approve plugin:111f0504-d4d8-4ee5-bd80-57bce3e8525a allow-once",
    "/agentkit approve plugin:111f0504-d4d8-4ee5-bd80-57bce3e8525a allow-always",
    "/approve plugin:111f0504-d4d8-4ee5-bd80-57bce3e8525a deny"
  ],
  "allowedHookResult": {
    "blocked": false,
    "params": {
      "cmd": "echo agentkit-allow"
    },
    "approvalResolution": "allow-once"
  }
}

Observed result after fix: plugin approval prompts render external verification as command text/selectable TUI actions, core deny remains available, verified allow resolution is approval-scoped and plugin-owned, and the companion AgentKit plugin can continue the protected call after proof-backed allow-once.

What was not tested: a fresh live World App QR scan from this exact OpenClaw PR head after today's rebase. The companion AgentKit branch includes docs/manual-tui-e2e.md for that full user-facing TUI recording path.

clawsweeper · 2026-05-16T04:22:16Z

Codex review: needs changes before merge. Reviewed June 30, 2026, 9:38 PM ET / 01:38 UTC.

Summary
The branch adds externalResolution metadata for plugin approvals, a plugin.approval.resolveVerified Gateway/protocol/SDK path, renderer/UI/TUI support, docs, and focused tests.

PR surface: Source +1106, Tests +1235, Docs +53, Generated 0, Other +26. Total +2420 across 56 files.

Reproducibility: not applicable. this is a feature/API PR, not a current-main bug report. Current main and v2026.6.11 source lack externalResolution and plugin.approval.resolveVerified, so there is no existing behavior to reproduce.

Review metrics: 1 noteworthy metric.

Public approval API surfaces: 1 request field, 1 Gateway method, 1 SDK helper. These are compatibility-sensitive plugin and Gateway contracts that need maintainer approval before release.

Stored data model
Persistent data-model change detected: migration/backfill/repair: src/commands/doctor-whatsapp-responsiveness.test.ts, serialized state: extensions/discord/src/approval-handler.runtime.test.ts, serialized state: src/plugins/contracts/session-actions.contract.test.ts, unknown-data-model-change: src/plugins/contracts/session-actions.contract.test.ts, vector/embedding metadata: extensions/discord/src/approval-handler.runtime.test.ts, vector/embedding metadata: extensions/slack/src/approval-handler.runtime.test.ts, and 2 more. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #82336
Summary: This PR is the implementation candidate for the open external HITL plugin approval API tracking issue; the broader resolver issue overlaps the trust-boundary question but is not a direct replacement.

Members:

canonical: Expose plugin approval APIs needed by external HITL plugins #82336 - The issue body names this PR as the implementation and defines the externalResolution plus resolveVerified acceptance criteria.
partial_overlap: Feature: a registerable, authoritative approval-resolver seam (capability-level, cross-harness, exclusive) for external approval providers #97152 - The issue proposes a broader capability-level, exclusive, proof-bound approval resolver that overlaps the resolver authority decision.
partial_overlap: Expose plugin approval action metadata #82431 - The earlier merged approval action metadata PR covered a related broader action surface, while this PR narrows the shape to externalResolution and verified resolution.
adjacent_distinct: Expose chat.inject metadata for plugin approval updates #82471 - The chat/status metadata PR was a related AgentKit host-API slice, but the current PR body says it is not required for this narrowed end-to-end path.
adjacent_distinct: [Feature]: Support external tool authorization providers through trusted tool policy hooks #97998 - The closed issue discusses external authorization provider documentation and light extension, adjacent to but not replacing this concrete resolver PR.

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

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

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

Rank-up moves:

[P2] Fix resolved-retry validation for resolveVerified and add a regression test.
Rebase the conflicting branch on current main and rerun the focused approval/Gateway tests.
Get explicit maintainer approval for the public resolver trust boundary.

Mantis proof suggestion
A short visual proof would help reviewers see the TUI/UI external verification choices and protected-call continuation, even though the main blocker is API/security review. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis visual task: verify the external plugin approval flow shows Verify once, Verify and trust for session, and Deny, and that verified allow continues the protected call.

Risk before merge

[P1] The PR publishes new Gateway/protocol/plugin SDK approval surfaces; once released, external plugins can depend on the exact resolver semantics.
[P1] The verified resolver disables approval-client visibility and currently lets already-resolved same-decision retries return success before pluginId/externalResolution validation runs.
[P1] Maintainers are still discussing broader approval-resolver direction in Feature: a registerable, authoritative approval-resolver seam (capability-level, cross-harness, exclusive) for external approval providers #97152, which may supersede this narrow AgentKit-shaped API.
[P1] Live GitHub mergeability is CONFLICTING/DIRTY against current main, so the branch needs a rebase before final validation.

Maintainer options:

Fix verified retry validation (recommended)
Ensure resolveVerified applies pluginId and externalResolution decision checks to already-resolved same-decision retries before returning success.
Approve the narrow resolver contract
Maintainers can accept operator.approvals plus pluginId owner matching as the public API contract after the retry validation gap and conflicts are fixed.
Pause for the broader resolver design
Hold or close this PR if maintainers want the capability-scoped, exclusive, proof-bound resolver tracked in Feature: a registerable, authoritative approval-resolver seam (capability-level, cross-harness, exclusive) for external approval providers #97152 instead.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Ensure plugin.approval.resolveVerified applies pluginId and externalResolution validation on already-resolved idempotent retries as well as pending resolves, and add regression coverage for a wrong pluginId retry after the correct plugin has already resolved the approval.

Next step before merge

[P2] A narrow automated repair can fix the resolved-retry validation gap, but maintainers still need to approve the API/security direction before merge.

Security
Needs attention: The diff intentionally changes an approval authorization boundary and has a concrete resolved-retry owner-validation gap to fix before merge.

Review findings

[P2] Validate verified retries before returning success — src/gateway/server-methods/plugin-approval.ts:302

Review details

Best possible solution:

Keep the plugin-owned external verification seam only if maintainers approve the public resolver contract, fix the resolved-retry validation gap, rebase, and keep the broader resolver design tracked separately.

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

Not applicable; this is a feature/API PR, not a current-main bug report. Current main and v2026.6.11 source lack externalResolution and plugin.approval.resolveVerified, so there is no existing behavior to reproduce.

Is this the best way to solve the issue?

No, not yet. The implementation is a plausible narrow host seam, but it is not the best merge-ready solution until resolved retries preserve owner validation and maintainers choose this API over the broader resolver design.

Full review comments:

[P2] Validate verified retries before returning success — src/gateway/server-methods/plugin-approval.ts:302
resolveVerified disables approval-client visibility, but handleApprovalResolve returns { ok: true } for an already-resolved same-decision retry before running validateDecision. That means a caller with operator.approvals can pass another pluginId for a resolved approval and still get success, bypassing the owner/externalResolution checks this API promises. Run the same validation for resolved retries or perform the owner check before using the visibility bypass.
Confidence: 0.87

Overall correctness: patch is incorrect
Overall confidence: 0.84

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

P2: This is a normal-priority feature/API improvement with limited immediate blast radius but meaningful approval-flow and plugin-contract impact.
merge-risk: 🚨 compatibility: The diff expands Gateway protocol and plugin SDK approval surfaces that external plugins may depend on after release.
merge-risk: 🚨 security-boundary: The diff changes who can complete plugin-owned approvals and introduces a concrete resolved-retry owner-validation gap.
rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR body includes after-fix live output from focused OpenClaw Gateway/TUI checks and a companion AgentKit local E2E run showing external verification commands and proof-backed allow continuation.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix live output from focused OpenClaw Gateway/TUI checks and a companion AgentKit local E2E run showing external verification commands and proof-backed allow continuation.

Evidence reviewed

PR surface:

Source +1106, Tests +1235, Docs +53, Generated 0, Other +26. Total +2420 across 56 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	34	1181	75	+1106
Tests	18	1275	40	+1235
Docs	2	53	0	+53
Config	0	0	0	0
Generated	1	2	2	0
Other	1	26	0	+26
Total	56	2537	117	+2420

Security concerns:

[medium] Verified retry skips owner validation — src/gateway/server-methods/plugin-approval.ts:302
Because resolveVerified disables client visibility and the shared resolved-repeat path returns success before validateDecision, same-decision retries can succeed with the wrong pluginId after the approval is already resolved.
Confidence: 0.87

Acceptance criteria:

[P1] node scripts/run-vitest.mjs src/gateway/server-methods/plugin-approval.test.ts.
[P1] git diff --check.

What I checked:

Repository policy read: Full root AGENTS.md and relevant scoped guides for gateway, server methods, plugin SDK, plugins, agents, TUI, extensions, UI, and docs were read before review. (AGENTS.md:1, b3b51b0c9185)
Current main lacks the requested API: Current main has no externalResolution or plugin.approval.resolveVerified approval API matches; only unrelated verified helper names were found. (b3b51b0c9185)
Current plugin approvals expose only the existing resolve path: Current main's plugin approval handler exposes list, request, waitDecision, and resolve, with no verified external resolver path. (src/gateway/server-methods/plugin-approval.ts:151, b3b51b0c9185)
Latest release also lacks the API: v2026.6.11 plugin approval schema has pluginId, allowedDecisions, and resolve params but no externalResolution or resolveVerified schema. (packages/gateway-protocol/src/schema/plugin-approvals.ts:17, e085fa1a3ffd)
PR adds public protocol surface: The PR adds PluginApprovalExternalResolutionSchema, externalResolution on PluginApprovalRequestParamsSchema, and PluginApprovalResolveVerifiedParamsSchema. (packages/gateway-protocol/src/schema/plugin-approvals.ts:53, c081a10a276c)
PR adds plugin hook API surface: The PR adds requireApproval.externalResolution to the plugin before-tool-call hook result type. (src/plugins/hook-before-tool-call-result.ts:25, c081a10a276c)

Likely related people:

joshavant: Introduced async before_tool_call requireApproval and the original plugin approval Gateway path that this PR extends. (role: introduced behavior; confidence: high; commits: 6ade9c474cf1; files: src/gateway/server-methods/plugin-approval.ts, src/infra/plugin-approvals.ts, src/plugins/hook-before-tool-call-result.ts)
pgondhi987: Authored requester-metadata approval access binding, central to the visibility model that the new verified resolver bypasses. (role: approval access contributor; confidence: high; commits: 386d321634b3; files: src/gateway/server-methods/approval-shared.ts, src/gateway/server-methods/plugin-approval.ts, src/gateway/operator-approvals-client.ts)
vincentkoc: Recently worked on shared approval lookup state and plugin id prefix restoration in the same approval surface. (role: recent area contributor; confidence: medium; commits: 5adc681238c6, 0e47ce58bc1b; files: src/gateway/server-methods/approval-shared.ts, src/gateway/server-methods/plugin-approval.ts)
steipete: Recent history shows same-chat approval routing and gateway approval helper refactors around the same approval delivery and visibility paths. (role: adjacent approval routing contributor; confidence: medium; commits: bb01e49192d3, 3ec000b99554, 574d3c521358; files: src/gateway/server-methods/plugin-approval.ts, src/gateway/server-methods/approval-shared.ts)
kevinslin: Merged the earlier related plugin approval action metadata PR and commented that approvals/reviews direction was under maintainer discussion. (role: API direction signal; confidence: medium; commits: 0c867eef756e; files: src/gateway/server-methods/plugin-approval.ts, src/infra/plugin-approvals.ts, ui/src/ui/controllers/exec-approval.ts)

What the crustacean ranks mean

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

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.

kevinslin · 2026-05-31T16:05:23Z

Having a discussion right now with some other maintainers about this because we are overhauling approvals and reviews with auto review. Will have more details in a few days

openclaw-barnacle · 2026-06-12T05:13:17Z

This assigned pull request has been automatically marked as stale after being open for 27 days.
Please add updates or it will be closed.

Guardiola31337 · 2026-06-12T11:43:43Z

quick update: rebased this on latest main and resolved the stale merge conflicts. The refreshed branch preserves the recent approval-runtime hardening from main and keeps this PR scoped to the external verified-resolution path.

Local verification:

pnpm plugin-sdk:api:check
pnpm protocol:check
git diff --check origin/main...HEAD
focused approval/gateway/UI/channel Vitest coverage via node scripts/run-vitest.mjs ... (7 shards, 550 tests)
pnpm tsgo:core
pnpm tsgo:core:test
pnpm lint --threads=8
pnpm check:docs

GitHub CI is running on the refreshed head now.

openclaw-barnacle · 2026-06-13T05:06:53Z

This assigned pull request has been automatically marked as stale after being open for 27 days.
Please add updates or it will be closed.

Guardiola31337 · 2026-06-13T11:30:38Z

quick keep-alive/status bump: this PR is still active and waiting on maintainer review while the approval/API discussion settles.

The branch was refreshed on latest main yesterday, conflicts were resolved, and GitHub CI is green on the current head. No new action needed from my side right now, just keeping this from going stale while review is pending.

openclaw-barnacle · 2026-06-14T05:13:33Z

This assigned pull request has been automatically marked as stale after being open for 27 days.
Please add updates or it will be closed.

openclaw-barnacle · 2026-06-15T05:10:34Z

This assigned pull request has been automatically marked as stale after being open for 27 days.
Please add updates or it will be closed.

openclaw-barnacle · 2026-06-16T05:03:14Z

This assigned pull request has been automatically marked as stale after being open for 27 days.
Please add updates or it will be closed.

Guardiola31337 · 2026-06-27T16:46:22Z

Updated after the RFC cleanup / Kevin feedback pass.

What changed:

rebased on current origin/main (2720ac06b7)
pushed the TUI selector path so users can choose Verify once, Verify and trust for session, or Deny instead of typing commands
clarified the resolver trust boundary in docs/comments: operator.approvals authority; pluginId is a pending approval owner selector, not authenticated plugin identity
updated the PR body with the RFC link, issue link, AgentKit companion PR, diagrams, current scope, and latest verification
updated Expose plugin approval APIs needed by external HITL plugins #82336 so it no longer asks for the older broad actions / chat.inject / status-card surface

Latest local verification:

/Users/pabloguardiola/.cache/codex-runtimes/codex-primary-runtime/dependencies/node/bin/node scripts/run-vitest.mjs src/gateway/server-methods/plugin-approval.test.ts src/tui/tui-plugin-approval-selector.test.ts src/tui/tui-event-handlers.test.ts src/tui/tui-command-handlers.test.ts src/tui/components/chat-log.test.ts
- gateway shard: 2 files, 78 tests passed
- TUI shard: 4 files, 176 tests passed
/Users/pabloguardiola/.cache/codex-runtimes/codex-primary-runtime/dependencies/node/bin/node scripts/docs-list.js
git diff --check origin/main...HEAD

@clawsweeper re-review

clawsweeper · 2026-06-27T16:46:25Z

🦞🧹
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.

Guardiola31337 · 2026-06-27T16:54:17Z

Follow-up: addressed the two CI failures from the latest push.

check-test-types: fixed the TUI test harness callback typing for approval snapshot / selector callbacks.
checks-fast-contracts-plugins-a: restored plugins.sessionAction to read the pinned HTTP route plugin registry while keeping main's stricter descriptor validation, so gateway session actions survive active runtime swaps.

Local verification after the fix:

/Users/pabloguardiola/.cache/codex-runtimes/codex-primary-runtime/dependencies/node/bin/node scripts/run-vitest.mjs src/plugins/contracts/session-actions.contract.test.ts src/gateway/server-methods/plugin-approval.test.ts src/tui/tui-plugin-approval-selector.test.ts src/tui/tui-event-handlers.test.ts src/tui/tui-command-handlers.test.ts src/tui/components/chat-log.test.ts
PATH="/Users/pabloguardiola/.cache/codex-runtimes/codex-primary-runtime/dependencies/node/bin:/Users/pabloguardiola/.cache/codex-runtimes/codex-primary-runtime/dependencies/bin:$PATH" pnpm check:test-types
git diff --check

openclaw-barnacle · 2026-06-28T04:54:21Z

This assigned pull request has been automatically marked as stale after being open for 27 days.
Please add updates or it will be closed.

openclaw-barnacle · 2026-06-29T04:58:53Z

This assigned pull request has been automatically marked as stale after being open for 27 days.
Please add updates or it will be closed.

openclaw-barnacle · 2026-07-08T04:31:42Z

Closing due to inactivity.
If you believe this PR should be revived, post in #clawtributors on Discord to talk to a maintainer.
That channel is the escape hatch for high-quality PRs that get auto-closed.

openclaw-barnacle Bot added docs Improvements or additions to documentation app: web-ui App: web-ui gateway Gateway runtime size: M triage: mock-only-proof Candidate: PR proof only shows tests, mocks, snapshots, lint, typecheck, or CI. labels May 16, 2026

Guardiola31337 mentioned this pull request May 16, 2026

Expose plugin approval action metadata #82431

Merged

Guardiola31337 force-pushed the agentkit/verified-approval-resolution branch from e3210b7 to adc699b Compare May 16, 2026 04:35

clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label May 16, 2026

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label May 16, 2026

Guardiola31337 force-pushed the agentkit/verified-approval-resolution branch 2 times, most recently from e79f8f4 to 1e7ce2d Compare May 16, 2026 06:35

clawsweeper Bot added proof: sufficient ClawSweeper judged the real behavior proof convincing. and removed proof: sufficient ClawSweeper judged the real behavior proof convincing. labels May 16, 2026

Guardiola31337 force-pushed the agentkit/verified-approval-resolution branch 8 times, most recently from a341cf3 to 8f276f1 Compare May 16, 2026 11:52

Guardiola31337 mentioned this pull request May 16, 2026

ci: avoid opengrep installer pipefail #82564

Closed

1 task

Guardiola31337 force-pushed the agentkit/verified-approval-resolution branch 3 times, most recently from f53379e to 3e0f127 Compare May 16, 2026 14:17

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label May 23, 2026

clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label May 23, 2026

Guardiola31337 force-pushed the agentkit/verified-approval-resolution branch from 233585a to dc3e1c7 Compare May 23, 2026 23:47

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label May 23, 2026

clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label May 23, 2026

Guardiola31337 force-pushed the agentkit/verified-approval-resolution branch from dc3e1c7 to da8c3cc Compare May 24, 2026 01:04

Guardiola31337 mentioned this pull request May 29, 2026

feat: implement external verification approvals Guardiola31337/openclaw-agentkit#2

Open

clawsweeper Bot mentioned this pull request Jun 18, 2026

Expose plugin approval APIs needed by external HITL plugins #82336

Open

9 tasks

This was referenced Jun 27, 2026

Feature: a registerable, authoritative approval-resolver seam (capability-level, cross-harness, exclusive) for external approval providers #97152

Open

docs: propose plugin-owned external verification approvals openclaw/rfcs#15

Merged

Guardiola31337 added 3 commits June 27, 2026 18:41

feat: add external plugin approval verification

9137856

feat(tui): surface plugin approval choices

f72188c

docs: clarify external approval trust boundary

6a24ba8

fix(tui): satisfy approval CI checks

c081a10

clawsweeper Bot mentioned this pull request Jun 30, 2026

[Feature]: Support external tool authorization providers through trusted tool policy hooks #97998

Closed

clawsweeper Bot mentioned this pull request Jul 25, 2026

feat(approvals): add external verification contract #113517

Open

Uh oh!

Uh oh!

Conversation

Guardiola31337 commented May 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Review context

Trust boundary

Why this shape

Verification

Real behavior proof

Uh oh!

clawsweeper Bot commented May 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kevinslin commented May 31, 2026

Uh oh!

openclaw-barnacle Bot commented Jun 12, 2026

Uh oh!

Guardiola31337 commented Jun 12, 2026

Uh oh!

openclaw-barnacle Bot commented Jun 13, 2026

Uh oh!

Guardiola31337 commented Jun 13, 2026

Uh oh!

openclaw-barnacle Bot commented Jun 14, 2026

Uh oh!

openclaw-barnacle Bot commented Jun 15, 2026

Uh oh!

openclaw-barnacle Bot commented Jun 16, 2026

Uh oh!

Guardiola31337 commented Jun 27, 2026

Uh oh!

clawsweeper Bot commented Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Guardiola31337 commented Jun 27, 2026

Uh oh!

openclaw-barnacle Bot commented Jun 28, 2026

Uh oh!

openclaw-barnacle Bot commented Jun 29, 2026

Uh oh!

openclaw-barnacle Bot commented Jul 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Guardiola31337 commented May 16, 2026 •

edited

Loading

clawsweeper Bot commented May 16, 2026 •

edited

Loading

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading