feat(chat): agents can render interactive views inline in the chat

[tusharbhardwaj-bk]

The problem

Agents can describe a chart, a diagram or a table, but they cannot show one.
Everything they produce arrives as text or as a collapsed tool row, so anything
visual has to be rebuilt in the reader's head — or opened somewhere outside the
conversation, which loses the place in the work it belonged to.

Hosts like Claude Desktop solved this with MCP Apps (SEP-1865, the first
official MCP extension, finalized 2026-01-26): a tool result points at a ui://
resource and the host renders it in a sandboxed iframe inline in the chat. This
brings the same capability to T3.

What this adds

A new t3_show_ui tool on T3's own MCP server. An agent calls it with a
self-contained HTML document (or an https URL) and the chat mounts it as a
sandboxed box in the transcript, right where the tool call happened.

The iframe has an opaque origin: its styles and scripts run, so charts and
interactions work, but it cannot reach T3 Code, its cookies, or the network as
the signed-in user.

Renders are immutable. Calling the tool again shows a new box rather than
mutating an old one, so scrolling back still shows what the agent actually
produced at that point in the thread.

Why it is built this way

The document never travels on an activity payload. The tool stores it and
returns only a short render handle; ActivityPayloadProjection carves that
handle out before it summarizes the result away, and the chat fetches the body
on demand through a new thread-scoped fork RPC.

That matters for two reasons. It keeps oversized documents off the websocket and
clear of the 32 KiB activity string cap. And it works on every provider —
including Claude Code, whose CLI flattens MCP tool results to text and would
otherwise drop an embedded ui:// resource entirely. Codex passes MCP content
blocks through verbatim; Claude does not. Routing through our own tool sidesteps
the difference.

The handle extractor reads three result shapes (text content array,
structuredContent, bare result object) because providers disagree about where
a result lands and a miss here fails silently.

Fork surface

Deliberately small, per AGENTS.md. New fork-owned modules carry the feature:

• apps/server/src/agentui/, persistence/AgentUiRenders.ts, migration 1022
• packages/contracts/src/agentUi.ts, packages/client-runtime/src/state/agentUi.ts
• apps/web/src/fork/agentUiSurface.tsx

Upstream files take one marked seam each. The timeline seam is one import plus
an early return that wraps the unchanged upstream row — composition, not
modification — so turning the setting off leaves exactly the original row
behind.

Gated by Settings → Experiments → Agent views in chat, on by default.

Verification

• AgentUiService.test.ts — 7 tests: storage round-trip, thread scoping (a
  render does not leak across threads), height clamping, https-only URL scheme
  (rejects http, javascript:, file:, data:), html/url exclusivity, size
  cap, missing render.
• ActivityPayloadProjection.agentUi.test.ts — 7 tests pinning handle survival
  through the projection in both provider nestings and all three result shapes,
  plus that ordinary MCP results are untouched and the body is still summarized.
• agentUiSurface.test.ts — 5 tests on the pure resolver, which runs on every
  work-log row and must stay total.
• Typecheck clean: contracts, server, web. Fork marker check passes. Lint clean.

Screenshots to follow from the expbkt3 deploy.

Written by Claude Opus 5 in T3 Code.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}