[VS Code Extension] "Unsupported content type: server_tool_use" shown repeatedly in chat transcript

Summary

The VS Code extension's chat webview shows a visible "Unsupported content type: server_tool_use" placeholder in the transcript, repeatedly (multiple times per request), whenever the model's response stream includes a server_tool_use content block. The block is fully understood by the stream parser (it's tracked for completion and token-usage accounting) but has no corresponding UI rendering case, so it falls through to the generic "unknown content type" placeholder.

This is cosmetic (the rest of the response still renders correctly), but it clutters the transcript on essentially every turn that uses a server-executed tool.

Environment

• Extension: Anthropic Claude Code for VS Code, v2.1.207 (also reproduced against the current latest Marketplace build, v2.1.209 — see "Confirmed still present" below)
• VS Code: 1.128.0 (commit fc3def6774c76082adf699d366f31a557ce5573f), Linux x64
• Claude Code CLI: 2.1.206
• OS: Linux 6.17.0-35-generic

Steps to reproduce

1. Open a Claude Code chat session in the VS Code extension in a project/config where server-executed tools are available — in my case, a session with a large set of "deferred tools" (MCP tools, WebFetch, WebSearch, CronCreate, etc.) that get resolved on demand via the Tool Search Tool.
2. Send a request that causes the model to invoke a server-side tool (in my case, resolving deferred tools via Tool Search — this happens organically, not via any special user action).
3. Observe the chat transcript.

Expected behavior

The server_tool_use content block renders with an appropriate UI treatment (e.g. similar to how tool_use blocks show a tool-invocation badge/header), or is silently skipped if it's not meant to be user-visible — consistent with how type: "fallback" blocks are already handled (rendered as null).

Actual behavior

Each server_tool_use block renders as:

Unsupported content type: server_tool_use

This appears multiple times per request, proportional to how many server-tool invocations occur in that turn.

Root cause (found via static analysis of the shipped bundle)

In webview/index.js, the content-block renderer has an explicit if/else if chain over e.content.type, handling tool_use, tool_result, fallback, and thinking, then falls through to a generic placeholder for anything else:

// ...else if(e.content.type==="tool_result"){ ... }
// else if(e.content.type==="fallback")return null;
// else if(e.content.type==="thinking"){ ... }
return E("div",{className:sx.unknownContent,children:["Unsupported content type: ",b("code",{children:e.content.type})]})

There is no else if(e.content.type==="server_tool_use") branch.

By contrast, the stream-parsing code in the same bundle does already recognize server_tool_use explicitly, e.g.:

if(t.type==="tool_use"||t.type==="server_tool_use")tit(t); // content_block_stop handling
// ...
}else if(e.type==="server_tool_use"){let n=e;if(!n[Z_])n[Z_]="";n[Z_]+=i.partial_json} // input_json_delta handling
// ...
if(t.usage.server_tool_use!==null)e.usage.server_tool_use=t.usage.server_tool_use // usage accounting

So the block type is fully modeled through parsing and usage tracking — the gap is specifically in the render switch that maps content blocks to UI.

Confirmed still present in the latest published version

I downloaded the current Marketplace build (2.1.209) directly from https://anthropic.gallerycdn.vsassets.io/extensions/anthropic/claude-code/2.1.209/.../Microsoft.VisualStudio.Services.VSIXPackage and diffed the equivalent code path. The structure is identical (only minified local variable names differ due to normal bundling churn) — server_tool_use still has no render case:

// 2.1.209, same shape as 2.1.207:
// ...else if(e.content.type==="tool_result"){...}
// else if(e.content.type==="fallback")return null;
// else if(e.content.type==="thinking"){...}
return E("div",{className:sx.unknownContent,children:["Unsupported content type: ",b("code",{children:e.content.type})]})

So this isn't fixed by updating to the latest available release.

Suggested fix

Add a render case for content.type === "server_tool_use" in the same switch, e.g. treating it similarly to tool_use (showing an invocation badge/header with the server tool's name) or, at minimum, returning null like fallback does so it doesn't surface a raw "unsupported" placeholder to end users.

Suspected trigger in practice

The repeated, near-every-request nature of this strongly suggests it's tied to the Tool Search Tool (deferred/just-in-time tool resolution) rather than an unusual or rarely-used feature — i.e. this will affect a large share of users who have MCP servers or many available tools configured, not just an edge case.

Happy to provide the full extracted bundle diff or a redacted session transcript if useful.