Pasted images are labelled unsupported in Claude sessions even though the model receives them

A pasted image in a Claude session is attached, sent, and understood by the model, but the UI marks it as unsupported: the attachment renders with a warning icon and the hover reads "*{model}* does not support images."

The model demonstrably receives it — asked about the image contents, Claude describes them correctly. Only the labelling is wrong, so the effect is that users believe the attachment was dropped and stop pasting images.

### Cause

The native (BYO-Anthropic / SDK) transport hardcodes the capability rather than reading it:

```ts
// claudeAgent.ts — fromSdkModelInfo
export function fromSdkModelInfo(m: ModelInfo, provider: AgentProvider): IAgentModelInfo {
return {
provider,
id: m.value,
name: m.displayName,
supportsVision: false, // <-- always
...
};
}
```

The CAPI/proxied projection right above it does read it — `supportsVision: !!supports?.vision` — so the two transports disagree about the same underlying models.

That flows to the attachment widget, which treats the flag as authoritative:

```ts
const supportsVision = modelSupportsVision(currentLanguageModel);
const pillIcon = dom.$('div.chat-attached-context-pill', {}, dom.$(supportsVision ? '…codicon-file-media' : '…codicon-warning'));
…
if ((!supportsVision && currentLanguageModel) || omittedState === OmittedState.Full) {
element.classList.add('warning');
hoverElement.textContent = localize('chat.imageAttachmentHover', "{0} does not support images.", …);
}
```

### The wrinkle

`ModelInfo` in `@anthropic-ai/claude-agent-sdk` has no vision field — it carries `supportsEffort`, `supportedEffortLevels`, `supportsAdaptiveThinking`, `supportsFastMode`, `supportsAutoMode`, but nothing for vision. So `false` looks like a stand-in for "the SDK does not tell us".

Defaulting to `false` turns "unknown" into a positive claim that is wrong for every Claude model currently reachable through this transport, and `agentHostLanguageModelProvider` collapses `undefined` to `false` anyway (`vision: m.supportsVision ?? false`), so leaving it unset changes nothing.

That makes `true` the accurate default for this transport unless and until the SDK exposes the capability. Happy to send that one-liner, or a version that plumbs a real capability through if you would rather not assert it — I did not want to change what the model catalogue asserts without asking.

### Version

- VS Code 1.133.0, commit `a5b500951314efd502d07465bd138dfbd714a960`
- Claude session over the native SDK transport, dev container remote

*AI disclosure: this issue was written with the assistance of AI.*

### Public patches and patcher scripts

[Public patch catalog and patcher scripts](https://github.com/RyanEwen/vscode-patches/blob/main/CATALOG.md) · [Source patch index](https://github.com/RyanEwen/vscode-patches/blob/main/SOURCE-PATCHES.md). The [public collection](https://github.com/RyanEwen/vscode-patches) includes the maintained patchers, rollback instructions, regression scripts, and historical snapshots. Build restrictions and exact installer coverage are documented there.