Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [RFC] Control UI plugin contribution slots [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#71736•Fetched 2026-04-26 05:09:04
View on GitHub
Comments
1
Participants
1
Timeline
2
Reactions
0
Author
100yenadmin100yenadmin
Participants
100yenadmin100yenadmin
Timeline (top)
commented ×1cross-referenced ×1

Add data-driven Control UI contribution slots for plugin chat modes, approval cards, event classifiers, input guards, and status surfaces.

This is proposed SDK surface, not currently implemented API.

Root Cause

Plan Mode should not patch mode-switcher, app-tool-stream, app-render, chat views, or custom CSS to become visible in the web UI. A first-class plugin needs UI contribution descriptors exposed by the gateway and rendered by safe host-owned components.

The same primitive applies to approval workflows, release dashboards, budget warnings, incident banners, memory/context panels, channel auth/delivery cards, review gates, and workspace policy guards.

Fix Action

Fix / Workaround

Plan Mode should not patch mode-switcher, app-tool-stream, app-render, chat views, or custom CSS to become visible in the web UI. A first-class plugin needs UI contribution descriptors exposed by the gateway and rendered by safe host-owned components.

  • Manifest vs runtime contribution projection.

  • Initial host-owned component catalog.

  • Event classifier descriptor shape.

  • Input guard behavior and whether guards disable, annotate, or both.

  • Disablement semantics for projected descriptors.

  • Whether chat mode entries can invoke plugin session patch actions directly.

  • Versioning for the UI descriptor schema.

  • Fixture chat mode appears only when plugin is enabled.

  • Fixture approval payload renders through a generic card slot.

  • Fixture action sends the expected plugin patch action.

  • Input guard reflects projected plugin session state.

  • Disabling the plugin removes UI contributions.

  • Descriptor sanitization prevents arbitrary browser code execution.

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.registerControlUiContribution({
  chatModes,
  approvalRenderers,
  eventClassifiers,
  inputGuards,
  statusSurfaces,
});
RAW_BUFFERClick to expand / collapse

Summary

Add data-driven Control UI contribution slots for plugin chat modes, approval cards, event classifiers, input guards, and status surfaces.

This is proposed SDK surface, not currently implemented API.

Why this matters

Plan Mode should not patch mode-switcher, app-tool-stream, app-render, chat views, or custom CSS to become visible in the web UI. A first-class plugin needs UI contribution descriptors exposed by the gateway and rendered by safe host-owned components.

The same primitive applies to approval workflows, release dashboards, budget warnings, incident banners, memory/context panels, channel auth/delivery cards, review gates, and workspace policy guards.

Current SDK surface

OpenClaw currently has remote/plugin slash command discovery and generic plugin approval request/card rendering. Chat input has host-local connected/busy/send checks, and tool/event rendering is hardcoded around known streams, tool ids, and card unions.

Those surfaces are useful but insufficient: generic plugin approvals cover one card class, but there is no broader registerControlUiContribution(...) registry for chat modes, input guards, status surfaces, event classifiers, or plugin-owned descriptor projection.

Proposed solution

Add a declarative contribution surface such as:

api.registerControlUiContribution({
  chatModes,
  approvalRenderers,
  eventClassifiers,
  inputGuards,
  statusSurfaces,
});

The first version should use safe host-owned components and descriptor schemas, not arbitrary plugin JavaScript in the browser.

Reusable plugin examples

  • Plan Mode contributes Plan/Plan Auto modes, approval/question cards, composer guards, and status indicators.
  • Human approval plugins render approval cards and pending banners.
  • Release plugins show rollout progress, deploy approval cards, and freeze banners.
  • Budget plugins show spend meters, override cards, and blocked-input hints.
  • Memory/context plugins show context panels, source visibility cards, and memory pickers.
  • Incident plugins show severity banners, SLA countdowns, and ticket action cards.
  • Channel plugins show auth cards, delivery status, and channel-specific input guards.
  • Workspace policy plugins show policy warning cards and blocked-action explanations.

Decisions needed

  • Manifest vs runtime contribution projection.
  • Initial host-owned component catalog.
  • Event classifier descriptor shape.
  • Input guard behavior and whether guards disable, annotate, or both.
  • Disablement semantics for projected descriptors.
  • Whether chat mode entries can invoke plugin session patch actions directly.
  • Versioning for the UI descriptor schema.

Acceptance criteria

  • Fixture chat mode appears only when plugin is enabled.
  • Fixture approval payload renders through a generic card slot.
  • Fixture action sends the expected plugin patch action.
  • Input guard reflects projected plugin session state.
  • Disabling the plugin removes UI contributions.
  • Descriptor sanitization prevents arbitrary browser code execution.

References

extent analysis

TL;DR

Implement a declarative contribution surface using the proposed registerControlUiContribution API to enable plugins to contribute UI components without patching existing code.

Guidance

  • Review the proposed solution and reusable plugin examples to understand the requirements for the new contribution surface.
  • Discuss and decide on the key aspects of the implementation, such as manifest vs runtime contribution projection, initial host-owned component catalog, and event classifier descriptor shape.
  • Ensure that the implementation meets the acceptance criteria, including fixture chat mode appearance, approval payload rendering, and input guard behavior.
  • Consider the security implications of the new contribution surface and ensure that descriptor sanitization prevents arbitrary browser code execution.

Example

api.registerControlUiContribution({
  chatModes: [
    { id: 'plan-mode', label: 'Plan Mode' },
    { id: 'plan-auto-mode', label: 'Plan Auto Mode' },
  ],
  approvalRenderers: [
    { id: 'approval-card', component: ApprovalCard },
  ],
  eventClassifiers: [
    { id: 'event-classifier', component: EventClassifier },
  ],
  inputGuards: [
    { id: 'input-guard', component: InputGuard },
  ],
  statusSurfaces: [
    { id: 'status-surface', component: StatusSurface },
  ],
});

Notes

The implementation of the new contribution surface will require careful consideration of the trade-offs between flexibility and security. The proposed solution provides a good starting point, but the details of the implementation will depend on the specific requirements and constraints of the project.

Recommendation

Apply the proposed solution using the registerControlUiContribution API, as it provides a declarative and flexible way for plugins to contribute UI components without patching existing code. This approach will enable a more modular and maintainable architecture.

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#ssr#installation#tensor shape#request timeout

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [RFC] Control UI plugin contribution slots [1 pull requests, 1 comments, 1 participants]