[Bug]: Custom ACP html_render succeeds but inline panel missing for editor_t3_code_<id> tool namespace #29130

Before submitting

• Searched existing issues; found related provider-specific reports below, but no report for editor_t3_code_<id> tool names.
• Included observed ACP output, parser reproduction, environment, and native-provider comparison.

Area

packages/contracts or packages/shared; ACP provider integration

Summary

Custom ACP connection completes html_render and returns render metadata plus “Shown to the reader above your reply”, but no inline panel appears. Stored activity names tool editor_t3_code_f6129534.html_render. T3's shared resolver rejects that name.

Switching same conversation to native Codex and calling native T3 html_preview, then html_render, produces inline panel successfully. Failure concerns this custom ACP path; not evidence that all ACP providers fail.

Steps to reproduce

1. Use custom ACP provider that exposes T3 MCP tools under namespace editor_t3_code_<id>. Observed connection used Hermes-backed custom ACP, provider instance hazel-acp, model openai-codex:gpt-6.1-sol.
2. Ask agent to display HTML inline using T3 html_preview, then html_render.
3. Call succeeds and returns htmlRender reference, but thread shows no inline panel.
4. Inspect conversation activity: tool name remains editor_t3_code_f6129534.html_render; result appears inside ACP text content.
5. Switch conversation to native Codex provider and repeat through native T3 tools. Inline panel appears.

Minimal HTML for reproducing provider behavior:

<!doctype html><html><body><p>ACP render test</p></body></html>

Observed failure used larger storage chart. Minimal HTML above is suggested reduction, not separately tested through ACP.

Expected behavior

Successful T3-owned render appears inline when called through supported custom ACP integration. Canonical tool identity and render reference survive provider translation. Success message should not silently imply visible delivery when client cannot recognize result.

Actual behavior

No inline panel despite successful result. User repeatedly reported missing panel.

Sanitized activity excerpt; attachment ID replaced:

{
  "toolName": "editor_t3_code_f6129534.html_render",
  "output": [
    {
      "type": "content",
      "content": {
        "type": "text",
        "text": "mcp__editor_t3_code_f6129534__html_render result\n- **result:** {\"htmlRender\":{\"attachmentId\":\"<thread>-<render>-html\",\"title\":\"Main SSD storage analysis\",\"height\":1013},\"message\":\"Shown to the reader above your reply. Don't mention or describe the page; reply with only what it doesn't already say.\"}"
      }
    }
  ]
}

Actual reference also includes responsive heights array, omitted here.

Confirmed parser behavior

Downloaded current upstream packages/shared/src/t3McpToolPresentation.ts on November 2, 2026 and executed its exported resolveT3McpToolId with Node's TypeScript stripping. GitHub content blob SHA: 864bcd8950d4127f64fc643bcad871c80c1b4248.

editor_t3_code_f6129534.html_render       => null
mcp__editor_t3_code_f6129534__html_render => null
t3-code.html_render                      => html_render
mcp__t3_code__html_render                 => html_render
unrelated.html_render                   => null

Current shared resolver recognizes canonical T3 namespaces but not observed generated namespace. htmlRenderFromToolItem immediately returns undefined unless resolver returns html_render.

This establishes name rejection, sufficient to prevent extraction through that function. Wrapped ACP text result may require separate normalization too; changing name alone has not been tested as complete fix. Exact ownership between custom connector and T3 ACP adapter remains for triage.

Please preserve server identity checks; accepting arbitrary *.html_render names would let unrelated tools impersonate T3 renders. Suggested acceptance coverage: genuine custom ACP call produces recognized identity and extractable reference; panel visible; unrelated/spoofed tool remains rejected.

Impact

Major degradation or frequent failure: inline HTML unavailable through observed custom ACP connection, with misleading success message.

Version or commit

Installed T3 client runtime: 0.1.6. Initial source inspection used local Talaria fork checkout at 31ff8f482b; parser rejection independently reproduced against current upstream source as described above. No application patch applied.

Environment

Ubuntu 24.04 host; Node v22.23.3 during original diagnosis. T3 Code custom ACP connection, then native Codex comparison in same conversation on November 2, 2026. Exact custom ACP implementation version and client browser version not captured.

Related reports

• html_render pages never show for Kiro threads because Kiro titles T3 tool calls @t3-code/<tool> #28230: Kiro @t3-code/<tool> titles lose identity; related symptom, different namespace.
• html_render pages never show for Grok threads because the result arrives in output.OkayOutput #23714: Grok wrapped OkayOutput result.
• [Bug]: html_render pages never show for OpenCode 2 threads because Code Mode wraps the call in execute #16745: OpenCode 2 execute wrapper.
• fix: html_render pages show inline when OpenCode or ACP agents wrap the call #17031: related wrapped-render handling PR.

Workaround

Use native Codex connection with native T3 HTML tools; verified in same conversation. No connector or T3 code changed.