3ccf2a0739
Adds client-capability-gated tool availability: gateway clients declare capabilities at connect (new inline-widgets cap), chat.send stamps them into the run context, and every tool assembly path (embedded runner, queued followups, Codex app-server harness, plugin-only construction plans) drops tools whose requiredClientCaps the originating client did not declare. The Canvas plugin ships the first such tool, show_widget: agents pass SVG or an HTML fragment plus a title; the plugin hosts it as a bounded, retention-scoped Canvas document and returns the existing canvas preview handle, which web chat renders as a sandboxed iframe fitted to the widget's reported content height. Widget frames never get allow-same-origin (per-preview sandbox ceiling, including the sidebar path) and the Canvas host serves widget documents with a CSP sandbox header so direct navigation runs in an opaque origin. Verified live end-to-end on a Testbox with gpt-5.5 (screenshots on the PR). CLI-backed model backends do not carry client caps yet and stay fail-closed (#102577). Closes #101790
2.9 KiB
summary, title, sidebarTitle, read_when
| 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 currently covers the embedded runner and the Codex app-server backend. CLI-backed model backends do not yet carry client capabilities, so capability-gated tools stay unavailable (fail closed) on those backends.
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.