fix(server): show html_render pages that Code Mode scripts publish#19029

Problem

OpenCode 2 runs T3's MCP tools inside its execute tool (Code Mode), so an html_render call shows up as a generic execute row. Clients only show a page for a completed tool call named html_render, so the page never appears, and thread deletion uses the same check, so the page file is left behind. It's worse than the simplest case in the issue: when the script returns something else, wraps the result, renders more than one page, or throws after rendering, nothing in the thread even references the page.

Repro: OpenCode 2 thread, ask for a small chart published with html_render. The page is written to the attachments dir, the agent's reply says it's above, and the thread shows only a folded execute row.

Change

The server already knows the calling thread when html_render runs, so it now records the page in that thread itself, the same way request_secret records its card:

• HtmlRender.publish stores the page, then, if the thread has a live run, dispatches a new internal html_render.record command for it. The thread comes from the MCP caller's scope, never from tool input or output.
• The orchestrator turns that into an html_render turn item on the run's root node. It refuses a page whose id was minted for another thread, a run that isn't active in the thread, and a thread that was deleted in the meantime. The item id and command id derive from the page id, so a retried publish doesn't record twice. The command is internal, so no client can dispatch it over the RPC.
• Web and mobile show recorded pages with the existing page row. A shared threadHtmlRenders helper also dedupes: a direct html_render call (Codex, Claude, Cursor, ...) whose page was recorded shows as an ordinary tool row, so the page appears once. A call with no recorded item (published outside a run, or history from before this change) still shows its page from the tool result like today.
• Thread deletion includes recorded pages, in both projection store paths.
• If recording fails, it's logged and the tool still returns its result, so direct calls behave as before. A publish interrupted before recording still removes its file, and one interrupted while the record commits keeps it. If the thread is deleted between storing the page and recording it, the page is removed and the call fails, since deletion already snapshotted the thread's pages.

Surfaces: web and desktop (shared timeline logic), mobile (feed builder, plus the icon/summary switches), contracts (new turn item and internal command; older clients drop the unknown item type through the existing forward-compatible decoding and keep showing direct calls), MCP thread reads (turnItemText), every provider (recording doesn't depend on tool names or result envelopes), delete (cleanup) and revert (items of a rolled-back run are already hidden). The page row, size limits and sandboxing are unchanged; recorded pages carry the same bounded reference the tool returns.

Scope and approval

Fixes #16745. Follows the fix proposed in the triage comment there (https://github.com/pingdotgg/t3code/issues/16745#issuecomment-6032382868): record each published page for its thread in the html_render handler instead of depending on the wrapping tool's name.

Why not #17031

Thanks to @ehfreema for the report and for #17031. We looked at it first and went with the server-side record instead, for three reasons:

1. It renders any htmlRender reference an execute result contains. A Code Mode script can return another thread's page id, and the client would show that page inline without an ownership check. We reproduced this on web and mobile.
2. It only covers a script that returns html_render's result directly. Pages stay hidden and orphaned when the script returns something else, wraps the result, renders two pages, or fails after rendering, which are the other cases listed in the issue.
3. Smaller: the new text-block parsing reads through a separate budget, so it sidesteps the tool output size limit.

Verification

Focused tests:

• apps/server/src/orchestration-v2/HtmlRenderRecord.test.ts (new, real orchestrator on in-memory SQLite): two pages recorded in the running turn on the run's root node, a replay records nothing new, another thread's page id, an unknown run, an ended run and a deleted thread are refused, getThreadAttachmentIds returns both pages for deletion.
• apps/server/src/htmlRender/HtmlRender.test.ts: publish records each page in the live run; no live run records nothing; a failing record still keeps the page and returns the reference; an interruption while the record commits keeps the page; a delete that lands before the record removes the page.
• packages/shared/src/htmlRender.test.ts: threadHtmlRenders shows every recorded page whatever the script returned, including a failed execute; a direct call plus its recorded page shows once; a direct call without a record still shows; a page id returned in an execute result is never shown; recorded pages are clamped like tool results.
• apps/web/src/session-logic.test.ts: Code Mode script plus recorded page; direct call shows once; the incremental path drops the direct call's copy when the recorded page streams in after it.
• apps/mobile/src/lib/threadActivity.test.ts: same two cases for the mobile feed, including the cached-row case.
• apps/server/src/attachmentStore.test.ts, packages/contracts/src/rpc.test.ts (clients can't dispatch html_render.record), apps/server/src/mcp/toolkits/core.test.ts.

All pass.

Live run on web: a dev server on this branch and one on its base (6524a8d437), OpenCode 2.0.22 with Code Mode on and Claude Sonnet 5.5. Both got the same prompt: call html_render from inside execute to publish a small bar chart.

Before	After
Two folded execute rows and no page. Expanding the second one shows the script's html_render call and the page reference it returned.	The page shows above the reply.
	One script that renders two pages and returns "done": both pages show, in order.

The same change has also been running in our fork on desktop, iPhone and iPad. The throw-after-render case was checked by the tests above, not in a live run.

Built with Claude Opus 5.5 in T3 Code (OpenCode harness). Reviewed with GPT-6 Astra.