[Bug]: Pasting an unsupported document leaves the chat unrecoverable

[fredrikbernholm]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

Not sure

Summary

Pasting an unsupported document into a T3 Code chat produces a media-type error and leaves the conversation unusable. There is no apparent way to recover and continue the same chat.

Steps to reproduce

Reported sequence:

1. Open a chat in T3 Code.
2. Paste a document that is not supported. In this case, the error identifies the file part as text/html.
3. Try to continue the conversation after the error appears.

The original document and a clean minimal reproduction are not available in this report.

Expected behavior

Reject unsupported attachments with an actionable error before they leave the conversation in a failed state. If an attachment fails after submission, provide a way to remove or discard it and continue the existing chat.

Actual behavior

The chat shows:

'file part media type text/html' functionality not supported.

After this error, the user cannot recover and continue the same conversation. The problem is the loss of a usable chat after an unsupported attachment is accepted.

Impact

Blocks work completely in the affected chat.

Version or commit

Not provided. Observed on September 16, 2026.

Environment

The affected provider/model and exact app version have not been confirmed.

Screenshots, recordings, or supporting files

The reporter supplied a screenshot showing the error above in red. The error is transcribed verbatim here.

Workaround

No recovery workaround was reported.

Related issues

• preview_snapshot includeImage embeds full-res base64 PNGs into tool history; providers that reject inline images brick the session permanently #11295 reports a similar unrecoverable-session outcome after browser screenshot tool results are stored in provider history. This report concerns a pasted document rejected as text/html; a shared root cause has not been established.
• [Bug]: HEIC attachments are accepted then rejected by the provider - "Unsupported Claude image attachment type 'image/heic'" #7225 covered unsupported HEIC attachments failing a turn and was closed after attach-time validation was added.

[juliusmarminge]

Triage

Confirmed in source. The quoted error is not a T3 string — it is Vercel AI SDK’s OpenAI-compatible converter ('file part media type ${mediaType}' functionality not supported). T3 reaches that path only through OpenCode.

Composer correctly treats a pasted .html / text/html document as a generic file (the image denylist from #6574 / #7225 does not apply). ProviderService already puts a filesystem path in the prompt. OpenCode then also sends the file as a native part because isOpenCodeNativeFilePart allows every text/* type:

• apps/server/src/provider/opencodeRuntime.ts (toOpenCodeFileParts)
• apps/server/src/provider/Layers/OpenCodeAdapter.ts (session.promptAsync parts)

That allowlist already excludes ZIP, BMP, SVG, and oversized PDFs so the model call does not fail before it starts. text/html was left on the native path. Many OpenCode model converters (especially OpenAI-compatible) reject it. Once the file part is stored in the OpenCode session, later prompts replay it and the same error returns — including on text-only follow-ups.

Claude, Cursor, Grok, and Codex never send generic files as native parts. Antigravity embeds text/* as text. So this is OpenCode-specific.

This is the same provider-history brick as #11295 (inline preview_snapshot PNGs), with a different trigger. Not a duplicate. #7225 / #6574 only gate unsupported images at attach time.

What prior work did not fix

Work	What it did	Why this still happens
#6574 (merged; closed #7225 / #6020)	Reject HEIC/SVG/etc. in the composer	HTML is classified as file, not unsupported-image
#8092 (file uploads)	Allow PDFs/ZIPs/other files	Intentional; OpenCode then over-promotes text/*
#4200	Validate before turn.started so the UI does not wedge on working	Session can still persist the rejected file part
#11295 (open)	Screenshot bytes in OpenCode history	Different payload; same inability to continue

No open T3 PR closes this.

Suggested fix

In isOpenCodeNativeFilePart:

1. Stop sending text/html (and likely other text/* types the converter rejects) as native file parts. Use the path line ProviderService already prepends. Folded clipboard pastes (source: pasted-text) already skip native parts.
2. Safest allowlist: PNG/JPEG/GIF/WebP + application/pdf. That matches the comment in toOpenCodeFileParts and the ZIP/BMP/SVG tests.
3. Do not add a global composer ban on HTML. Other providers already handle generic files without this converter.

A MIME change does not rewrite file parts already in an OpenCode session.

Workaround

• New HTML/text documents on OpenCode: attach as usual only after a fix; until then, paste as text or point the agent at a file path.
• Bricked chat: start a new thread. Rewind can work if it forks off the user message that carried the file part (OpenCodeAdapter.rollbackThread → session.fork). If the failed turn never created an assistant boundary, rewind to the last good turn or just start a new chat.

Implementable from current main. Confirming the OpenCode model slug would be useful but is not required.

Classification: bug · accepted · high (one paste can brick the OpenCode chat)
Labels: add bug, accepted, via-triage
Discord tags: providers, ui