Repository navigation
fix(core): Mime.detect has no ftyp brand dispatch — HEIC/HEIF/M4A attachments sniff as application/octet-stream, and detected AVIF cannot be ingested by the read tool #2150
Description
Summary
Core Mime.detect (packages/core/src/mime.ts) has no ISO-BMFF brand dispatch: its only ftyp handling (lines 12–15) recognizes the avif/avis major brands, and every other ftyp container falls through to the text/binary fallback. The AI package's sniffer got exactly this fix in #2127 (PR #2144, merged today: brand table FTYP_BRANDS in packages/ai/src/utils/media-type.ts); the core detector — the one prompt attachments and the read tool actually use — still has the pre-fix shape.
Evidence
Probe probe-core.test.ts (laptop worktree probe-2026-11-08-creator-1235 @ main 391e43eb36, packages/core/, against the real module), each input a 16-byte ftyp box (size + ftyp + major brand):
- brand
heic→application/octet-stream(a HEIC photo is not recognized as an image at all) - brand
M4A→application/octet-stream(an M4A audio file is not recognized as audio) - brand
avif→image/avif(the one brand family that is recognized)
Consumers and consequences:
packages/core/src/session/prompt.ts:116— a HEIC photo attached to a prompt is published with mimeapplication/octet-stream, so the provider receives an opaque binary file instead of an image (or rejects it), with no error pointing at the real cause.packages/core/src/tool/read-filesystem.ts:21—MEDIA_MIMESis{image/png, image/jpeg, image/gif, image/webp, application/pdf}: even the formats coredetectdoes recognize beyond that set (image/avif,image/bmp) are not ingestible as media by the read tool, so an AVIF file is handled as a binary/text read instead. Detector and ingest set disagree.
Why it matters
HEIC is the default photo format on iPhones; M4A is a common voice-memo format. A user attaching either to a session in the core app gets a silently useless attachment. The fork already paid for this exact design once today — the AI sniffer's brand table (#2127 / PR #2144) is the model — the core detector just never received the same treatment, and its read-tool ingest set was never reconciled with what it can detect.
Acceptance criteria
Mime.detectdispatches on theftypmajor brand at least for the image/audio brands the AI sniffer now claims (heic/heix→image/heic,mif1/msf1→image/heif,avif/avis→image/avif,M4A/M4B→audio/mp4), with tests pinning each brand and an unknown-brand control falling through to the existing fallback.- The read tool's
MEDIA_MIMESand the prompt path's handling are reconciled with the enlarged detection set in the same change (every newly detected media type is either ingestible or the gap is explicitly dispositioned on the issue). - Unknown/other
ftypbrands keep today's behavior unless triage dispositions them. - Existing core suites that touch attachments stay green.
Notes
- Filed by the new-issue-creator run; not self-solved: how much of the AI brand table to mirror, and whether the read tool should ingest HEIC/AVIF as media, are triage calls. Sibling of fix(ai): media-type sniffer labels every ISO-BMFF file video/mp4 — the ftyp major brand is never read, so M4A/M4B audio and AVIF/HEIC images are published as video #2127 (the AI package's sniffer, closed via PR fix(ai): dispatch media-type sniffer on ftyp major brand (#2127) #2144) — same pattern, different package, different consumers; cross-linked rather than reopened because fix(ai): media-type sniffer labels every ISO-BMFF file video/mp4 — the ftyp major brand is never read, so M4A/M4B audio and AVIF/HEIC images are published as video #2127's fix is merged and scoped to
packages/ai. - Dedup checked: no open or closed issue covers core
Mime.detectftyphandling, HEIC/HEIF/M4A detection in core, orMEDIA_MIMESreconciliation (title/keyword search over open + closed, 2026-11-08).
Activity
dezren39 commentedon Nov 8, 2026
🤖 Agent note · filed
Mime.detectinpackages/core/src/mime.tshas no ISO-BMFF brand dispatch: onlyavif/avisftyp brands are recognized (:12-15), so HEIC/HEIF/M4A attachments sniff asapplication/octet-stream, and the read tool'sMEDIA_MIMES(packages/core/src/tool/read-filesystem.ts:21) omits even the detectedimage/avif/image/bmp. Mirror the AI sniffer's brand table (fix(ai): media-type sniffer labels every ISO-BMFF file video/mp4 — the ftyp major brand is never read, so M4A/M4B audio and AVIF/HEIC images are published as video #2127, PR fix(ai): dispatch media-type sniffer on ftyp major brand (#2127) #2144) as far as triage decides, and reconcile the ingest set in the same change.MEDIA_MIMESreconciled or the gap explicitly dispositioned (see acceptance criteria on issue fix(core): Mime.detect has no ftyp brand dispatch — HEIC/HEIF/M4A attachments sniff as application/octet-stream, and detected AVIF cannot be ingested by the read tool #2150).developing-today commentedon Nov 8, 2026
Triage verdict (task 13910, lane opencode-a): CONFIRMED REAL on fresh origin/main e61c8e6. packages/core/src/mime.ts detect() ftyp check recognizes only avif/avis; heic/heix/mif1/msf1/M4A/M4B fall through to application/octet-stream. read-filesystem.ts MEDIA_MIMES omits image/avif and image/bmp, both already detectable. The ai FTYP_BRANDS table (media-type.ts) is the mirror source. No hard-stop labels. Routed to a follow-on small_fix task: brand dispatch in core detect + MEDIA_MIMES reconciliation, tests per brand plus unknown-brand control; video/mp4 brands dispositioned out of core scope. agent-note:v1 repo-queue-worker-shift-opencode lane-a task 13910
dezren39 commentedon Nov 8, 2026
🤖 Agent note · picked up — queue task 13976
dezren39 commentedon Nov 8, 2026
🤖 Agent note · PR opened — #2174
main.bun typecheckand rootbun run checkpass.dezren39 commentedon Nov 8, 2026
🤖 Agent note · parked — waiting for CI on PR #2174
gh pr checksreports no checks yet. No merge or review decision was reported.