[Feature] DSH chat cannot paste/upload non-image files — only images are accepted

[etzhe]

📌 更新 / Update — 2026-08-31 17:56 UTC+8
根据社区 @weijiafu14 与 @denial123789 的反馈（均已逐文件核对 rc.2 源码）修订：

• 主诉求明确为：把 attachment 抽象成与媒体类型无关的通用通道，图片只是其中一种渲染（而非简单放宽 imageLimits.mediaTypes）。
• 补充：通用附件需要一条从 composer 到工具的完整路径，而不只是 composer 那一段（否则"能贴上、模型读不到"，用户感受不到差别）。
• 采纳的边界：上传成功 ≠ agent 读到文档；需覆盖浏览器准入、不可变存储、媒体中立的持久引用、Session 授权检索、有界解析、模型可见证据、文件卡片回放；PDF/office/archive 需保留 extractor 版本/限制/警告/坐标/派生摘要，归档需独立 member/深度/扩展字节/压缩比边界。
• 相关：社区已有 dsh-file-upload / @tivility/dsh-file-upload 等包（装前须自查源码与权限面，并注意 Bug: installing any plugin that depends on @deepseek-ai/dsh-tools breaks every tool call (Cannot read properties of undefined (reading 'prepare')) #1697 的 @deepseek-ai/dsh-tools hoist 坑）。

Summary

In the DSH web interface (dsh web), Ctrl+V pasting a non-image file (e.g. .pdf, .xlsx, .docx, .txt, .zip) has no effect — the file "won't go in". Images (.png, .jpg, .webp, .gif) paste fine and appear as attachments. There is no file-upload / file-card affordance for general files either.

This blocks a very common workflow: users want to drop a spreadsheet or document on the agent to inspect it.

Expected behavior

Pasting (or dragging) any file should be accepted and attached, not just images. At minimum:

• Non-image files should be attachable (alongside images), shown as a file chip/card with name + size.
• Or, if the paste path stays image-only, provide an explicit "upload file" affordance (file picker / drag-drop target) for arbitrary files.

Environment

• @deepseek-ai/dsh version: 0.1.1-rc.2
• Browser: any (reproduced in Chromium/Playwright)

Root cause (I traced it — saving you time)

The clipboard-file path in the client always routes files into an image-only pipeline.

In packages/client/ui-conversation (dsh-client-ui-conversation), the onPaste handler does:

const onPaste = (e) => {
  ...
  const files = Array.from(e.clipboardData.items)
    .filter((item) => item.kind === "file")
    .map((item) => item.getAsFile())
    .filter((file) => file !== null);
  if (files.length > 0) intakeImages(files);   // <-- always goes to the IMAGE pipeline
  const text = e.clipboardData.getData("text/plain");
  ...
};

And intakeImages is image-specific:

const intakeImages = (files) => {
  if (imageLimits) {
    if (files.some((f) => !imageLimits.mediaTypes.includes(f.type))) return addImages(files);
    if (attachments.length + files.length > imageLimits.maxImagesPerMessage) return t("image.tooMany");
    if (files.some((f) => f.size > imageLimits.maxImageBytes)) return t("image.fileTooLarge");
    ...
  }
  return addImages(files);
};

imageLimits.mediaTypes (defined in dsh-client-connection / dsh-api-remotes) is limited to image/png | image/jpeg | image/webp (some places add image/gif). There is no separate channel or UI for general files — the attachment module dsh-client-ui-attachment is likewise image-oriented (onAddImages, MessageImage, ImageLightbox, ComposerAttachments, all image.* labels).

So a non-image file is pulled out of the clipboard but rejected by the image-type check (or simply has no UI to receive it) → appears as "paste had no effect".

Suggested approach

In onPaste / the attach path, branch by type:

• If file.type is in mediaTypes → current image pipeline (unchanged).
• Else → a new general-file attachment pipeline (or a file-picker / drop target that accepts */*).

This keeps image behavior intact while adding real file support.

Extra context

This is the same class of issue as the ApprovalPanel not rendering full details (private component, compiled-only distribution, no src shipped). The client packages ship compiled output only (files: ["lib/index.js", ...], build via tsdown, no src/), so there's no clean local override — a first-class, source-level fix is the right path.

Thank you!

[weijiafu14]

你的源码定位是对的（onPaste 无条件把所有 kind === "file" 的项目丢进 intakeImages，而 intakeImages 只认 imageLimits.mediaTypes）。但在等官方之前，这件事社区已经有人做了——两个包，都是拿来即用。

npm 上现成的两个

包	描述
dsh-file-upload（0.4.3）	DSH 双面插件：Claude 风格的拖拽 / 回形针上传
@tivility/dsh-file-upload（0.2.2）	拖拽上传到 DSH 工作区，带 ownerAuth 门控

（同一带上还有 dsh-file-browser、dsh-upload-button，以及针对具体格式的 dsh-pdf / dsh-pdf-mineru / dsh-univer-office——如果你的场景就是"把 xlsx/docx 丢给 agent 读"，格式专用的那几个可能比通用上传更直接。）

披露：这些全是别人的包，不是我的，我一个都没装过，上面只是照 npm 描述转述。装之前建议自己看一眼源码和权限面——尤其第二个带 ownerAuth，说明作者考虑过"谁能往工作区里写文件"这个问题，这在多人访问的部署里很重要。

还有一个装插件本身的坑要先知道：#1697 —— 装任何依赖 @deepseek-ai/dsh-tools 的第三方插件，都可能因为 profile 顶层 hoist 出一份同名副本而让每一次工具调用都失败（Cannot read properties of undefined (reading 'prepare')），受害的是整个 profile 而不只是新装的那个插件。那帖下面有两个离线诊断器可以装完自查一下。

这些包的存在，反过来是你提案最好的论据

我建议你把它们写进原帖，而不是当成"那就不用提了"：

两个独立作者各自实现了同一件事，说明这不是小众需求；而他们都得自己造一条上传通道（因为 dsh-client-ui-attachment 整个是 image-oriented：onAddImages / MessageImage / ImageLightbox / image.* 文案），说明缺的是一个通用附件通道，而不是"少支持了几个 MIME 类型"。

这个区分对提案很重要：

• 如果诉求写成"请把 imageLimits.mediaTypes 放宽"——那只是让非图片文件进入一条为图片设计的管线（缩略图、lightbox、"图片过多"的文案、按图片数量算的上限），结果多半是别扭的；
• 如果写成"请把 attachment 抽象成与媒体类型无关的通道，图片只是其中一种渲染"——那才是你自己在 Expected behavior 里描述的那个东西（"file chip/card with name + size"）。

你已经把两条路都列出来了，建议把第二条明确成主诉求。

一个相关的、你可能想一起提的事实

即使文件能附上去了，模型那边能不能用它是另一回事。这一带最近有几条相关报告：

• #4612：原生 read_image 工具因为一处 scope 传错，在所有预设上都直接失败（cannot get property "fs" without inject）；
• #4615：dsh-llm-pi-ai 把非 png/jpeg/gif 的图片原样发出去。

也就是说，附件这条链路目前在客户端和服务端两侧都有已知缺口。如果你的提案能顺带指出"通用附件需要一条从 composer 到工具的完整路径，而不只是 composer 那一段"，会更完整——光能贴上去、模型读不到，用户感受不到差别。

边界与利益相关

我们不修 DSH 自家组件——ui-conversation 的 onPaste、ui-attachment、imageLimits 都在 DSH 里。上面推荐的包全是别人的，我没装过；#1697 / #4612 / #4615 也都是别人的报告。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——我们不做文件上传，上面那两个上传插件和我们没有任何关系。

[denial123789]

I verified this against current rc.2 source and agree that the missing abstraction is broader than MIME acceptance. The image vocabulary continues past onPaste:

• the conversation service creates only draft objects with kind: "image" and serializes image inputs;
• AttachmentStore exposes validateImage, saveImage, and readImage;
• ImageAttachmentRef requires raster dimensions and verified image media types;
• session.attachment has a useful Session-reference authorization join, but its response vocabulary is still image-specific.

So widening imageLimits.mediaTypes would either fail byte decoding or weaken a real integrity boundary. A complete general-file path needs separate contracts for browser admission, immutable storage, a media-neutral durable reference, Session-authorized retrieval, bounded parsing, model-visible evidence, and file-card replay. Upload success alone must not imply that the Agent read the document.

One additional security gate worth including: parser provenance and truncation must survive replay. For PDF/office/archive inputs, record extractor version, limits, warnings, coordinates, and derived-artifact digest; otherwise the model can appear to cite content that was never extracted. Archive expansion also needs independent member, depth, expanded-byte, and compression-ratio bounds.

I turned the current source map, reference design, safe rc.2 workspace workaround, failure router, and fifteen acceptance gates into an independent architecture guide: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/integrations/general-file-attachments.md

Affiliation: I maintain this SandBase handbook. It is an independent community project, not official DeepSeek AI documentation.

[etzhe]

感谢这么详细的回复，尤其是帮我分清"少支持几个 MIME"和"缺通用附件通道"这两件事的区别。你说得对——我会把诉求从"放宽 imageLimits.mediaTypes"改成"把 attachment 抽象成与媒体类型无关的通道，图片只是其中一种渲染"，这才对应我想要的那个 file chip/card with name + size。

模型那边读不读得到，我之前确实没充分意识到。谢谢点出 #4612（read_image 因 scope 传错在所有预设上失败）和 #4615（dsh-llm-pi-ai 把非 png/jpeg/gif 图片原样发出）。我会在帖子里补一句：通用附件需要一条从 composer 到工具的完整路径，而不只是 composer 那一段。

你提到的两个上传包我会按你说的先看源码和权限面，也会注意 #1697 那个"依赖 @deepseek-ai/dsh-tools 的插件可能让整个 profile 工具调用全崩"的坑。谢谢不推销的坦白。