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
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:
The first version should use safe host-owned components and descriptor schemas, not arbitrary plugin JavaScript in the browser.
Reusable plugin examples
Decisions needed
Acceptance criteria
References
docs/plan/plan-mode-plugin-host-hooks-rfc.md