b5ba0771f9
* test: shorten loopback token fixtures below secret-scanner thresholds * feat: carry gateway client capabilities through the CLI loopback backend CLI-backed model runs now transport the originating client's declared capabilities along the existing per-field loopback contract: RunCliAgentParams gains clientCaps, prepare emits OPENCLAW_MCP_CLIENT_CAPS, the loopback header template forwards x-openclaw-client-caps, the request context parses and normalizes it (grant-authenticated callers keep ignoring spoofable headers), and the loopback tool cache keys on a stable caps serialization so capless and capped requests never share tool lists. Capability-gated tools such as show_widget now work on CLI backends; the CLI session binding hash includes caps, consistent with messageProvider. Cron and command-attempt runs stay capless (fail closed). Fixes #102577
2.9 KiB
| summary | title | sidebarTitle | read_when | ||
|---|---|---|---|---|---|
| Render self-contained SVG or HTML widgets inline in web chat | Show widget | Show widget |
|
show_widget renders a self-contained SVG or HTML fragment inline in the Control UI chat transcript. The bundled Canvas plugin owns the tool and hosts each result as a same-origin Canvas document.
The tool is available only when the originating Gateway client declares the inline-widgets capability. The Control UI declares this capability automatically. Channel runs such as Telegram and WhatsApp do not receive show_widget.
Capability transport covers embedded, Codex app-server, and CLI-backed model backends. Grant-authenticated MCP callers and direct HTTP tool-invoke callers remain fail closed because they do not declare client capabilities.
Use the tool
The agent supplies two required strings:
Short title shown with the inline preview and in the hosted document title. Self-contained SVG or HTML fragment. Input beginning with `The tool result includes a Canvas preview handle, so web chat renders the widget directly from the tool call and restores it after history reload. Transcripts that do not render previews still show the hosted Canvas path.
Security and storage
Widget documents use a restrictive Content Security Policy: inline style and script are allowed, images may use data: URLs, and external fetches and resource loads are blocked. Keep all markup, styles, scripts, and image data inside widget_code.
The iframe always omits allow-same-origin, even when the Control UI's global embed mode is trusted, so widget scripts cannot read the parent application origin. The Canvas host also serves widget documents with a Content-Security-Policy: sandbox allow-scripts response header, so opening the hosted URL directly still runs the widget in an opaque origin instead of the Control UI origin. Browser sandboxing does not prevent a script from navigating its own iframe; only render widget code you are willing to execute in that isolated frame.
The iframe also follows gateway.controlUi.embedSandbox. The default scripts tier supports interactive widgets while preserving origin isolation.
Canvas retains at most 32 widgets per session (or per agent when no session is available). Creating another widget removes the oldest document in that scope.