Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [RFC] Trusted tool policy stage and plugin tool metadata [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#71734•Fetched 2026-04-26 05:09:07
View on GitHub
Comments
1
Participants
1
Timeline
2
Reactions
0
Author
100yenadmin100yenadmin
Participants
100yenadmin100yenadmin
Timeline (top)
commented ×1cross-referenced ×1

Add a trusted pre-plugin tool policy stage and plugin-owned tool metadata so bundled/trusted plugins can enforce host-level policy and so plugin tools can appear with first-class catalog/display/safety metadata.

This is proposed SDK surface, not currently implemented API.

Root Cause

Plan Mode must block mutating tools while approval is pending. That gate must run before ordinary plugin before_tool_call hooks so another plugin cannot reorder, rewrite, or bypass the policy accidentally. Plan Mode tools also need catalog/display/safety metadata without hardcoded core tool catalog patches.

The same primitive applies to budget guards, deployment freezes, workspace policy plugins, dangerous-action wrappers, compliance plugins, and tool catalog extensions.

Fix Action

Fix / Workaround

Plan Mode must block mutating tools while approval is pending. That gate must run before ordinary plugin before_tool_call hooks so another plugin cannot reorder, rewrite, or bypass the policy accidentally. Plan Mode tools also need catalog/display/safety metadata without hardcoded core tool catalog patches.

PR fix notes

PR #71731: docs: add Plan Mode plugin host hook RFC

Description (problem / solution / changelog)

Summary

This PR is a maintainer RFC package for making Plan Mode a first-class bundled plugin without merging the large host patch from #71676.

  • Problem: #71676 proves Plan Mode behavior, but it embeds the feature across session state, gateway patching, agent turn preparation, pending injections, tool policy, commands, Control UI, agent events, scheduler/cron, heartbeat prompts, docs, QA, and channel flows.
  • Why it matters: maintainers prefer a plugin path. A plugin port cannot reach 100% parity unless OpenClaw first exposes generic host seams in the plugin SDK.
  • What changed: added an RFC packet, public index page, six issue-sized RFC threads, current-SDK gap research, reusable plugin matrices, a #71676 entry-point coverage map, and fixture-test expectations for a future implementation PR.
  • What did NOT change: this PR intentionally does not implement hooks, Plan Mode behavior, prompts, tools, UI cards, session fields, scheduler changes, or runtime SDK APIs.

RFC Status Warning

This is proposed SDK design, not implemented SDK reference. The docs now include explicit warning callouts, and the public page has been moved out of SDK reference into a dedicated Plugin design RFCs nav group.

RFC Decision Threads

  • #71732 — Plugin session extensions and patch actions
  • #71733 — Durable next-turn injections and agent turn preparation hooks
  • #71734 — Trusted tool policy stage and plugin tool metadata
  • #71735 — Scoped plugin commands, trusted command ownership, and continuation
  • #71736 — Control UI plugin contribution slots
  • #71737 — Agent events, run context, scheduler lifecycle, and heartbeat contributions

The issue bodies have been expanded so each thread includes: proposed/not-implemented status, current SDK surface, missing host seam, Plan Mode parity use, reusable non-Plan plugin examples, decisions needed, and fixture acceptance criteria.

RFC Contents

The full RFC packet covers:

  • current SDK research against existing hooks, using #71427 as the comparison bar
  • reusable SDK capability matrix across public SDK, trusted/bundled SDK, gateway protocol, UI descriptors, runner boundary, lifecycle cleanup, and fixture tests
  • plugin archetype matrix for approval workflows, deploy/release, budget guards, memory/context, review/CI, incidents/tickets, channel integrations, workspace policy, telemetry/exporters, and long-running jobs
  • #71676 entry-point coverage map for Plan Mode parity
  • per-hook TypeScript-shaped API sketches
  • expected host files for each implementation slice
  • authorization, trust-tier, disablement, cleanup, and failure semantics
  • fixture-plugin acceptance tests for the future hook implementation PR
  • Plan Mode migration sequence and parity checklist

Change Type

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Related #71676
  • Related #71732
  • Related #71733
  • Related #71734
  • Related #71735
  • Related #71736
  • Related #71737
  • This PR fixes a bug or regression

Verification

Verified locally:

  • pnpm format:docs:check
  • pnpm lint:docs
  • pnpm docs:check-mdx
  • pnpm docs:check-links

Human Verification

  • Confirmed the docs nav no longer places the proposal under stable SDK reference.
  • Confirmed both docs pages warn that the named APIs are proposed, not implemented.
  • Confirmed the RFC packet includes a #71676 entry-point coverage map.
  • Confirmed all six live issue bodies are expanded beyond Plan Mode-only examples.
  • Did not run runtime Plan Mode behavior because this PR is docs/RFC-only and implements no hooks.

Compatibility / Migration

  • Backward compatible? Yes, docs-only.
  • Config/env changes? No.
  • Migration needed? No.

Risks and Mitigations

  • Risk: reviewers mistake the RFC for implemented SDK reference.
    • Mitigation: warning callouts plus Plugin design RFCs nav placement.
  • Risk: proposal appears Plan Mode-specific.
    • Mitigation: reusable SDK matrices, non-Plan plugin examples, and expanded issue bodies.
  • Risk: proposal overclaims parity.
    • Mitigation: #71676 entry-point coverage map and explicit note that actual parity requires the future hook implementation PR plus fixture tests.

Next Step After This PR

If maintainers accept the RFC direction, the next PR should implement the generic host hooks with a tiny fixture plugin. Only after that should Plan Mode itself move into a bundled plugin and be audited against #71676 for parity.

Changed files

  • docs/docs.json (modified, +4/-0)
  • docs/plan/plan-mode-plugin-host-hooks-rfc.md (added, +1289/-0)
  • docs/plugins/plan-mode-plugin-host-hooks.md (added, +492/-0)

Code Example

api.registerToolPolicy({
  id,
  stage: "pre_plugin_hooks",
  trust: "bundled",
  handler,
});

---

api.registerToolMetadata({
  name,
  title,
  category,
  display,
  safety,
});
RAW_BUFFERClick to expand / collapse

Summary

Add a trusted pre-plugin tool policy stage and plugin-owned tool metadata so bundled/trusted plugins can enforce host-level policy and so plugin tools can appear with first-class catalog/display/safety metadata.

This is proposed SDK surface, not currently implemented API.

Why this matters

Plan Mode must block mutating tools while approval is pending. That gate must run before ordinary plugin before_tool_call hooks so another plugin cannot reorder, rewrite, or bypass the policy accidentally. Plan Mode tools also need catalog/display/safety metadata without hardcoded core tool catalog patches.

The same primitive applies to budget guards, deployment freezes, workspace policy plugins, dangerous-action wrappers, compliance plugins, and tool catalog extensions.

Current SDK surface

OpenClaw currently has before_tool_call, which can rewrite params, block, or require approval. Core config also filters tools before hook wrapping, and plugin tools have basic catalog fields.

Those surfaces are useful but insufficient: before_tool_call is a normal plugin hook, not a bundled/trusted pre-plugin policy tier. Plugin metadata is not a full display/safety registry, and core-owned tools such as update_plan cannot be safely decorated by plugins.

Proposed solution

Expose trusted policy registration such as:

api.registerToolPolicy({
  id,
  stage: "pre_plugin_hooks",
  trust: "bundled",
  handler,
});

Expose metadata registration such as:

api.registerToolMetadata({
  name,
  title,
  category,
  display,
  safety,
});

Maintainers must also decide whether bundled plugins can decorate core-owned tools such as update_plan, or whether those plugins should own parallel tools.

Reusable plugin examples

  • Plan Mode blocks mutating tools while approval is pending and labels Plan Mode tools.
  • Budget plugins block or require approval for expensive models/tools.
  • Workspace policy plugins block filesystem, browser, or network tools that violate path or data-egress rules.
  • Deployment plugins gate deploy and rollback tools during freeze windows.
  • Dangerous-action wrappers require scoped approval for high-risk mutations.
  • Compliance plugins add audit and safety labels to plugin-owned tools.
  • Tool catalog plugins publish display, risk, category, and ownership metadata without hardcoding host display maps.

Decisions needed

  • Trust tier for pre-plugin policy hooks.
  • Policy decision shape and terminal behavior.
  • Plugin tool display/safety metadata schema.
  • Whether core-owned tools such as update_plan can be decorated.
  • Disablement behavior for policy, metadata, and decorated tool state.
  • Negative enforcement for external/untrusted plugins attempting privileged policy registration.

Acceptance criteria

  • Fixture trusted policy blocks before ordinary before_tool_call hooks.
  • Normal plugins cannot override a trusted block.
  • External plugins cannot register trusted pre-plugin policy.
  • Fixture tool metadata appears in tool catalog and UI/tool display lookup.
  • Disabling the fixture plugin removes metadata, decoration, and policy.

References

extent analysis

TL;DR

Implement a trusted pre-plugin tool policy stage and plugin-owned tool metadata to enforce host-level policy and provide first-class catalog/display/safety metadata for bundled/trusted plugins.

Guidance

  • Expose trusted policy registration using api.registerToolPolicy to allow bundled plugins to enforce host-level policy before ordinary plugin hooks.
  • Expose metadata registration using api.registerToolMetadata to provide display/safety metadata for plugin-owned tools.
  • Determine the trust tier for pre-plugin policy hooks and decide whether core-owned tools can be decorated by bundled plugins.
  • Implement disablement behavior for policy, metadata, and decorated tool state to ensure proper removal of plugin functionality when disabled.

Example

api.registerToolPolicy({
  id: 'plan-mode-policy',
  stage: "pre_plugin_hooks",
  trust: "bundled",
  handler: (tool) => {
    // Block mutating tools while approval is pending
    if (tool.mutating && !approvalPending) {
      return { block: true };
    }
  },
});

Notes

The proposed solution requires decisions on trust tier, policy decision shape, and plugin tool display/safety metadata schema. The implementation should ensure that external/untrusted plugins cannot register trusted pre-plugin policy.

Recommendation

Apply the proposed solution by implementing the api.registerToolPolicy and api.registerToolMetadata methods, and determining the trust tier and decoration behavior for core-owned tools. This will provide a more robust and flexible policy enforcement mechanism for bundled/trusted plugins.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#installation#tensor shape#autograd error#model save/load

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING