[FEATURE]:Support drag-and-drop for Microsoft Office files (.docx, .xlsx)

[BWbear]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Description: Currently, the opencode chat interface does not support dragging and dropping Microsoft Office files (such as .docx and .xlsx). Users are forced to manually provide file paths or convert files to text/PDF before uploading.

Proposed Solution:

Expand the allowed file types in the frontend's drag-and-drop handler to include .docx and .xlsx.
Integrate a backend parsing mechanism (e.g., using python-docx and openpyxl) to convert these documents into a text-based format (like Markdown) that the LLM can process.
Use Case: Many software engineering and administrative tasks involve reading requirements or data stored in Office documents. Direct support would significantly improve the user experience and workflow efficiency.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [FEATURE]: Desktop should accept more dropped file types in prompt input #18143: Feature request for Desktop to accept more dropped file types in prompt input (same core request — expand supported drag-and-drop file types)
• [FEATURE]:It's recommended to drag and drop files in, and it should support more formats, such as .kt, .java, .xml, etc. #15177: Feature request to support more drag-and-drop file formats (e.g. .kt, .java, .xml)

Please review those issues and consider whether your request is already covered. If it is, adding a comment there with your specific use case (.docx/.xlsx + backend parsing) would help consolidate the discussion.

[GP-commits]

Hi! I would love to work on this feature. Could you assign it to me?

Here is my proposed implementation plan:

1. Frontend: Update \ACCEPTED_FILE_TYPES\ in \packages/app/src/constants/file-picker.ts\ to include .docx, .xlsx, and their MIME types.
2. Backend: Add \mammoth\ (for docx) and \xlsx\ (for Excel) to the dependencies in \packages/opencode/package.json.
3. Modify \packages/opencode/src/tool/read.ts\ to intercept .docx\ and .xlsx\ before they hit the binary file check. We will parse their contents into text/CSV and return it within <content>\ tags for the LLM to ingest natively.

Let me know if this approach sounds good or if you have any feedback before I submit a PR!

[buildgreatthings]

We use Opencode as a general harness for all our agent runs. I think an even simpler first change would start with:

1. Frontnend. Same as @GP-commits
2. Enable file passing to the LLM API endpoints. Anthropic and OpenAI already handle attachments natively.

A separate follow on PR would be great for support opensource models.

[bitfinop]

Adding our case for consolidation (as the dedupe bot suggested) — we hit this in a corporate rollout of opencode Desktop on a central config.

The angle that's slightly different from drag-and-drop: the “+” button / Cmd+U file picker filters selectable files by the model's modalities.input (text, image, audio, video, pdf) — so .docx/.xlsx and other office formats are simply greyed out and can't be attached at all.

Meanwhile the capability already exists elsewhere: the Read tool parses those same files fine once they're inside the project folder, and plugins (e.g. opencode-markitdown) convert them to Markdown. Only the picker blocks the path.

Two options from our users' perspective:

1. add a document modality for office formats, or
2. when attachments are handled tool-side, don't filter the picker — accept any file and route it through Read/conversion.

Observed on Desktop v1.17.18, macOS. Essentially the same request as #18143.

[jdecker76]

Adding our case: we run opencode against an internal gateway (LiteLLM proxy) that already handles Excel. The backend is fine with .xlsx — only the client drops it.

One correction to @bitfinop's note above — the picker doesn't filter on the model's modalities.input; I couldn't find that in the attachment path at all. The actual blockers are three hardcoded lists:

• ACCEPTED_FILE_TYPES in packages/app/src/constants/file-picker.ts — the picker allowlist
• attachmentMime() in prompt-input/files.ts — returns undefined for .xlsx (it's a ZIP, so it fails the text sniff), so the file is dropped after selection even if the picker lets it through. This logic is duplicated in session-ui/src/v2/components/prompt-input/attachments.ts.
• local-attachment.ts in the TUI — if (!mime.startsWith("image/") && mime !== "application/pdf") return

The server already passes arbitrary mime through as a base64 file part (session/prompt.ts), so this looks client-side only.

Would you take a config option extending the allowed types, reusing the existing attachment namespace?

{ "attachment": { "types": [".xlsx"] } }

Same token syntax that array already mixes (MIME, text/*, or .ext), appended to the defaults. No parsing and no new dependencies — deliberately not what #32104 attempted.

One design question before I start: when an accepted file's type is beyond what the model claims to support, should it be sent anyway and let the provider decide, or gated on capability? The former is what our proxy needs, and matches what the server does today.

[zukktest-cell]

Also affected on the desktop app (Windows). The attach button / file picker filters out .xlsx (and the attachment MIME sniffing rejects both .xls and .xlsx as binary), so spreadsheet files cannot be attached at all. Being able to drag-and-drop .xlsx and have it converted to Markdown tables (like the office-converter approach in the pending PRs) would be very useful. Looking forward to seeing this merged.