Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/app/src/components/prompt-input/attachment-routing.ts`:
- Around line 87-89: routeBrowserFile currently only checks OFFICE_EXTS and
falls back to reason "unknown", causing inconsistent routing versus
routePickedPath which checks TEXT_EXTS; update routeBrowserFile to compute the
file extension (using ext(file.name) as already done), then if
TEXT_EXTS.has(suffix) return { type: "path", reason: "text" } before the office
check or alongside it so .html/.txt/etc. are routed as text consistently with
routePickedPath; keep the existing OFFICE_EXTS check and fallback for unknowns.

In `@packages/app/src/components/prompt-input/attachments.ts`:
- Around line 107-116: The add function redundantly calls attachmentMime(file)
for route.type === "direct" even though routeBrowserFile already returns
route.mime; replace the async attachmentMime call with route.mime: after
obtaining route from routeBrowserFile (via routeBrowserFile and inspecting
route.type), use const mime = route.mime (or route.mime directly), check if mime
is falsy and call warn() and return false as before, then call await
dataUrl(file, mime) and pass file.name, mime into addDirect; remove the
attachmentMime(file) invocation and keep calls to routeBrowserFile, addDirect,
dataUrl, and warn unchanged.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/app/src/components/prompt-input/attachment-routing.ts`:
- Around line 3-4: InputKind currently only lists "image" | "pdf" while
ModelInputMap (and the backend's MediaInputKind) also include "audio" and
"video", causing a type mismatch and future confusion; update InputKind to
"image" | "pdf" | "audio" | "video" to match ModelInputMap and backend
MediaInputKind (or if you intentionally want to limit supported types, add a
clear comment above InputKind referencing that it's intentionally limited and
link to backend MediaInputKind), ensuring the symbols InputKind and
ModelInputMap remain consistent across frontend and backend.

In `@packages/app/src/components/prompt-input/attachments.ts`:
- Around line 71-81: warnRouteFailure contains a fallback warn() that is
theoretically unreachable because AttachRoute.direct denotes success and should
never be passed in; make this explicit by replacing the generic fallback with an
exhaustive check that signals a programmer error: convert the if-chain into a
switch or if/else blocks over route.type (handling "reject-image" ->
warnImageUnsupported, "path" -> pathRequired) and for any other case (e.g.,
route.type === "direct" or unexpected values) throw an explicit Error or call an
assertUnreachable helper mentioning warnRouteFailure and route.type so the
unreachable state is obvious at runtime and during typechecking (reference
warnRouteFailure, AttachRoute, warnImageUnsupported, pathRequired, warn, and
consider adding/asserting an assertUnreachable(route) or throw new
Error(`Unexpected AttachRoute in warnRouteFailure: ${route.type}`)).
- Around line 127-142: The addAttachments function redundantly calls
routeBrowserFile after add fails; change add(file, ...) to return the failure
AttachRoute (e.g., Promise<boolean | AttachRoute>) instead of just false so it
captures the route before returning, then update addAttachments to check the
returned value from add and set failure = returned AttachRoute when present (no
second routeBrowserFile call), preserving use of warnRouteFailure(failure) and
input.model() where needed.

In `@packages/desktop-electron/src/main/ipc.ts`:
- Around line 122-129: The "read-file-data-url" IPC handler currently reads any
path directly with fs.readFile, allowing arbitrary and oversized files; update
the handler to first validate that the supplied path was produced by your
approved picker flow (e.g. check a secure allowlist or token via a new helper
like isApprovedAttachment(path) or lookup in the picker-provided Map) and then
call fs.stat(path) to enforce the attachment size limit (compare size to
MAX_ATTACHMENT_BYTES) before reading; only if both checks pass call
fs.readFile(path) and return the base64 data URL, otherwise reject/return null
or throw a clear error.

---

Outside diff comments:
In `@packages/opencode/src/session/prompt.ts`:
- Around line 1094-1175: The code only applies the path-preservation/capability
gating for local parts when part.mime === "text/plain"; update the logic to
detect any local file part (e.g., part.url starting with "file:" or using
officePathOnly(filepath)) before the code path that converts local files to data
URLs and apply the same capability checks (use mediaInputKind(attachment.mime)
and modelCanReadMedia(model, kind)) and path-preservation behavior: if the
destination model cannot read the media, keep the file-as-path synthetic message
and attach the original part instead of converting to a data: URL. Locate and
modify the branch that currently handles text/plain and the later raw
fsys.readFile(...)->data: conversion so the gating runs once earlier (using
filepath, part.url, officePathOnly, execRead/provider.getModel/Exit handling)
for all local file parts regardless of MIME.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/opencode/src/session/prompt.ts`:
- Around line 1163-1181: The current filter keeps attachments when
mediaInputKind(attachment.mime) is undefined, allowing unknown/office types
(e.g., .docx) to be re-emitted as synthetic attachments; change the predicate in
the attachments creation so it only keeps attachments with a defined kind that
the model can read (i.e., require kind !== undefined && modelCanReadMedia(model,
kind)) before mapping to synthetic pieces; keep the existing fallback that
pushes the original { ...part, messageID: info.id, sessionID: input.sessionID }
when filtered attachments.length < result.attachments.length so unmapped/unknown
Read attachments preserve the original file: part.

---

Duplicate comments:
In `@packages/opencode/test/session/prompt.test.ts`:
- Around line 121-145: Replace the literal interpolated file URL strings with a
proper file URL via pathToFileURL(missing).href: in the prompt.prompt call (the
parts array) use pathToFileURL(missing).href instead of `file://${missing}`, and
update the assertion that checks for the file part URL (the msg.parts.some(...)
check) to compare against pathToFileURL(missing).href as well; import
pathToFileURL from 'url' if not already present and keep the rest of the logic
(prompt.prompt call and msg.parts checks) unchanged.