Feature idea: attach non-image files (PDF etc.) in the chat composer

[xiaoxuPekingUniversity]

Summary

The chat attachment pipeline is currently image-only: dsh-attachment-local admits only image/png|jpeg|webp|gif, and the composer rejects other files ("仅支持…格式的图片"). For document-heavy workflows — tutoring prep, reading exam PDFs, docs/code review — it would be very useful to drag a PDF (and later .docx/.xlsx) into the chat and have the agent read it from disk.

Where the restriction lives

• Host — dsh-attachment-local: image-only media-type allowlist + an image normalization pipeline (normalizedImageMaxDimension, normalizedImageMaxBytes, Sharp decode, etc.).
• Client — dsh-client-ui-attachment: README states "Images only — non-image files have no rail card or history renderer yet"; the composer drop target only accepts image drops.

Proposed change (minimal)

1. Host — add an optional non-image allowlist (pdf, txt, docx, …); store those files content-addressed without image normalization; enforce size/MIME checks.
2. Client — accept non-image drops; render a "document card" (file icon + name + size) in the draft rail and message history; keep existing image behavior unchanged.
3. Message model — extend the attachment reference with a kind (image vs document) so an agent can resolve a disk path (existing file-reference/local plumbing) and read it with any PDF tool.

Out of scope

Feeding PDF bytes into the model context. The goal is only durable attach + a disk reference the agent reads.

Reference implementation (stopgap)

We built a small MCP server + CLI + local drop inbox as a workaround while this isn't supported:
https://github.com/xiaoxuPekingUniversity/dsh-read-pdf (PDF text extraction, Chinese OCR, page render, file search, drag-drop inbox).

Happy to contribute the host + client changes as a PR if maintainers agree with this direction.

Environment

• dsh 0.1.1-rc.2 (npm install), Windows 11, Web surface

[denial123789]

The proposed split between Host storage and client rendering is the right starting point. One boundary I would keep out of the durable message model is a Host disk path: a browser filename is not a capability, remote Web may not share a filesystem with the Host, and absolute paths make replay/export depend on one storage layout.

I would make the feature three separately testable contracts:

1. Intake: picker/drop/paste create a neutral file draft; accept is only a UI hint, while the Host verifies bytes, MIME, quotas, and policy.
2. Durability: commit an immutable object plus Session-scoped opaque ref, then replay a document card with an explicit stored | processing | ready | limited | failed state. A multi-file message should publish only after all selected objects commit.
3. Agent usability: resolve that ref through a Session-authorized operation, then choose a bounded extractor or an exact provider-native route. The card being stored must not imply that the model read it.

For local workflows, “copy into workspace” can be an explicit approved materialization step returning a relative tool-visible path plus source digest. That workspace file is a derivative; it should not replace the original attachment identity. This keeps the current image path additive and avoids weakening Sharp-backed image validation.

I mapped the proposal against the pinned rc.2 composer/store/retrieval contracts, including acceptance gates and failure ownership, in this independent architecture guide: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/integrations/general-file-attachments.md