[Bug]: html_render pages never show for OpenCode 2 threads because Code Mode wraps the call in execute #16745

Activity

1. juliusmarminge commented on Oct 7, 2026

   

   juliusmarminge

   on Oct 7, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Thanks for the detailed report. I confirmed it against main (checked at 10f39eb9).

   Root cause

   • htmlRenderFromToolItem (packages/shared/src/toolOutput.ts:167-175) returns a page only when resolveT3McpToolId(item.toolName) === "html_render". It ignores the output otherwise.
   • OpenCode 2 Code Mode runs T3 tools inside execute, and OpenCodeToolItems.ts:155-167 (apps/server/src/orchestration-v2/Adapters/) projects that as dynamic_tool with toolName: "execute". The name check fails even when the output contains a valid htmlRender reference.
   • OpenCode2AdapterV2.ts:3264-3275 calls client.mcp.add(...) with a RemoteConfig that has no codemode field, so OpenCode's default (Code Mode on) applies.
   • Thread deletion uses the same check: threadHtmlRenderAttachmentIds (apps/server/src/attachmentStore.ts:122-135, called from ProjectionStore.ts:4618 and :5961). That means pages published through execute are orphaned when their thread is deleted.

   Proposed fix

   • Don't depend on the wrapping tool's name. The server's html_render MCP handler already knows the thread, so it should record each published page for that thread directly, for example as a thread attachment or a projection entry. Clients would then render it and deletion would clean it up, whatever provider or wrapper ran the call. This also covers scripts that never return the html_render result.
   • Smaller interim option: in htmlRenderFromToolItem, also accept an htmlRender reference from a completed execute item. Keep the existing parseThreadSegmentFromAttachmentId thread-ownership check so a script can't point at another thread's page.
   • Turning Code Mode off (codemode: false) isn't recommended, because every request would then carry every T3 tool schema (see [Bug]: Pi sessions declare every t3-code tool on every turn #16651).

   Workaround
   T3 Code has no in-app workaround yet. Published pages are still on disk as <thread>-…-html.html in the attachments directory, so you can open them by hand. Other providers (Claude, Codex, OpenCode 1) render pages normally.

   Related, not duplicates: #16140/#16142 (OpenCode 2 MCP wiring, fixed), #15736 (Code Mode catalog flapping), #16651 (schema bloat).
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 7, 2026
3. ricardo-devis-agullo commented on Oct 7, 2026

   

   ricardo-devis-agullo

   on Oct 7, 2026

   More actions

   Additional reproduction: Devin through ACP Registry

   I reproduced the same user-visible failure on the latest nightly with Devin running through T3's acpRegistry harness, but with a different failure mode from OpenCode's execute wrapper.

   Environment

   • T3 Code: 0.0.46-nightly.20261007.2774 (611132c171f3)
   • Provider instance: acpRegistry_devin
   • macOS arm64

   Observed behavior

   • html_preview succeeds with zero console errors.
   • html_render succeeds and writes the HTML file under ~/.t3/userdata/attachments/.
   • The projected turn item has the correct recognizable tool name: mcp__t3-code__html_render.
   • Nothing renders in the thread, even after reload/reopen.

   The important difference is the persisted output shape. The ACP adapter stores the tool result as:

   [
     {
       "type": "content",
       "content": {
         "type": "text",
         "text": "{\"htmlRender\":{\"attachmentId\":\"<thread>-<uuid>-html\",\"title\":\"...\",\"height\":408,\"heights\":[...]},\"message\":\"Shown to the reader above your reply...\"}"
       }
     }
   ]

   compactDynamicToolOutput() cannot extract this result. In readResult()'s array branch, it only reads block.text:

   const text = Predicate.isObject(block) ? block.text : undefined;

   For the ACP Registry shape, the JSON is at block.content.text, so readResult() receives undefined, htmlRenderFromToolItem() gets no htmlRender reference, and the client never creates an inline render row. The current tests cover { type: "text", text: json } and { content: [{ text: { text: json } }] }, but not [{ type: "content", content: { type: "text", text: json } }].

   A narrow compatibility fix would unwrap both block.text and block.content, then extract .text from either object shape. For example:

   const content = Predicate.isObject(block) ? (block.text ?? block.content) : block;
   const text = Predicate.isObject(content) ? (content.text ?? content) : content;
   const result = readResult(text, budget, depth + 1);

   This supports the broader fix proposed above: published pages should ideally be recorded directly against the thread, independent of provider-specific result envelopes. Until then, Devin-over-ACP users can successfully publish HTML files but cannot see them inline.

   👀React with 👀1Reacted by Ethan Hyatt Freeman
4. YL404 commented on Oct 8, 2026

   

   YL404

   on Oct 8, 2026

   More actions

   Additional reproductions: acpRegistry_codebuddy_code, plus a second gap beyond the tool name

   Reproduced on 0.0.46-nightly.20261008.2801 (macOS arm64) by reading orchestration_v2_projection_turn_items in ~/.t3/userdata/statev2.sqlite for every provider that ran html_render, and replaying each persisted output through readResult's logic:

   provider_instance_id	recorded toolName	name gate (resolveT3McpToolId)	recorded output shape	compactDynamicToolOutput().htmlRender
   codex (native)	t3-code.html_render	✅	{htmlRender:{…}}	✅ renders in the thread
   acpRegistry_devin	mcp__t3-code__html_render	✅ (see below)	[{type:'content',content:{type:'text',text:'<json>'}}]	❌
   opencode	execute	❌	{htmlRender:{…}}	✅ only the name is lost
   acpRegistry_codebuddy_code	Tool / DeferExecuteTool	❌	{type:'text',text:'<json>'} bare object	❌ would fail even with the right name

   Two details that look new relative to the discussion so far:

   1. acpRegistry_codebuddy_code fails both gates, and its output shape is not covered by the narrow fix proposed above. The agent wraps every injected MCP call in its own ToolSearch → DeferExecuteTool layer, so the wire title/kind is just Tool/DeferExecuteTool; the real name only survives inside rawInput.toolName (mcp__t3-code__html_render). Its output is a bare {type:'text',text:'<json>'} object — readResult's object branch looks for structuredContent/content, finds neither, and treats the block itself as data, so data.htmlRender is never read. Unwrapping block.text ?? block.content in the array branch won't reach this shape.

   2. Devin-over-ACP's name gate only passes by accident. extractMcpToolCallIdentity (apps/server/src/provider/acp/AcpRuntimeModel.ts) checks meta.is_mcp_tool_call + rawInput.server/rawInput.tool, meta.serverId/meta.toolName, claudeCode/goose meta, and the wire data.title. Devin's real name lives in meta['cognition.ai/inferenceToolName'] (which normalizeDevinToolCall copies into tool.title) and in rawInput.server_name/tool_name — none of which are candidates. The item therefore lands in the default branch: toolName = presentation title (which resolveT3McpToolId happens to regex-match), and output recorded verbatim with no acpMcpToolCallOutput normalization. Any less canonical title would fail the name gate too.

   Both reinforce the systemic direction proposed above: recording the published page against the thread at html_render call time fixes every one of these rows regardless of naming or envelope. If the interim narrow fix lands first, the readResult array branch should recurse into block.content (covers [{type:'content',content:{…}}]) and the object branch should try value.text when no content/structuredContent key exists (covers the bare {type:'text',text} block).
5. IsraelAraujo70 commented on Oct 8, 2026

   

   IsraelAraujo70

   on Oct 8, 2026

   More actions

   Additional reproduction: Grok Build (grok) wraps html_render in a UseTool MCP envelope

   Same user-visible failure on the latest nightly, with a Grok-specific envelope. Codex on the same machine, the same evening, renders the page.

   What happened

   Asked a Grok thread to publish a page with html_render. html_preview succeeded. html_render succeeded and wrote the HTML file. The thread never showed the page. One attempt painted a frame titled "October 8" that said "Image unavailable". A Codex thread running the same tool showed the page inline.

   Diagnosis

   Read orchestration_v2_projection_turn_items for the two threads. The Grok item that used the recognizable tool name still does not expose htmlRender where htmlRenderFromToolItem looks.

   Grok, inline use_tool call (variant: "UseTool"):

   • toolName: t3-code.html_render (the name gate passes)
   • input keys: tool_name, tool_input, variant. The document is at input.tool_input.html, not input.html
   • output:

   {
     "type": "MCP",
     "tool_name": "html_render",
     "server_name": "t3-code",
     "output": {
       "OkayOutput": "{\"htmlRender\":{\"attachmentId\":\"<thread>-<uuid>-html\",\"title\":\"October 8\",\"height\":2000,\"heights\":[...]},\"message\":\"Shown to the reader above your reply...\"}"
     }
   }

   OkayOutput is a JSON string. There is no output.htmlRender object.

   Codex, same night, native call:

   • toolName: t3-code.html_render
   • input keys: html, height, title
   • output: { "htmlRender": { "attachmentId", "title", "height", "heights" }, "message": "..." }
   • The page renders.

   Two earlier Grok attempts passed the HTML through a file. Those items are stored as:

   • toolName: t3-code__html_render — source file: /tmp/mcp-render.json

   That name fails resolveT3McpToolId before the envelope is even read. The HTML files were still written (three *-html.html files for this thread under the attachments directory).

   This is the same product gap as OpenCode's execute wrapper and the Devin / CodeBuddy envelopes already on this issue: the page is published, then the client only looks for a provider-specific tool name and a provider-specific result shape. Grok adds one more shape, { type: "MCP", output: { OkayOutput: "<json string>" } }, plus a tool name that sometimes has a "source file" suffix.

   Recording the published page on the thread inside the html_render handler would cover this row too. A narrower read of the Grok envelope would also need to parse output.output.OkayOutput when it is a string, and to accept the t3-code__html_render — source file: … title or ignore the suffix.

   Steps to reproduce

   1. Desktop app, Nightly, provider grok / grok-4.7-build-fast.
   2. Ask the agent to call html_preview, then html_render, with a small self-contained HTML document.
   3. The tool result reports htmlRender.attachmentId and the HTML file is on disk.
   4. The thread does not show the page. Codex html_render in another thread on the same app does.

   Version

   0.0.46-nightly.20261008.2819

   Environment

   macOS 26.5.2, T3 Code (Nightly) desktop app. Provider grok, model grok-4.7-build-fast. Compared with provider codex, model gpt-6.1-sol, on the same install.

   Evidence

   Grok thread 7614335e-d780-4175-9cde-b141a64c16a9. Codex thread where the page did render: bd78657b-5c88-4c5a-bc36-66c88f67f740. Successful Grok attachment id (file exists, page absent in the thread): 7614335e-d780-4175-9cde-b141a64c16a9-b15e5d09-3373-4768-85b7-9b83c9ba25c9-html.

   Workaround

   None in the Grok thread. The HTML file can be opened from the attachments directory. Codex renders the same tool normally.

   Filed by

   grok-4.7-build-fast, following the npx t3 triage playbook in-session. Did not launch a nested npx t3 triage agent, because that command starts an interactive Claude or Codex session.
6. AshutoshGitMirror commented on Oct 10, 2026

   

   AshutoshGitMirror

   on Oct 10, 2026

   More actions

   Can confirm on opencode v2 and antigravity ACP.