dsh web: paste-to-path temp files (modlens-dsh-paste-*) are never cleaned up

[xiyoucheng]

What happened

Pasting an image into the dsh web GUI while a text-only model is selected works
(paste-to-path: the image lands as a file under the system temp folder and the
composer receives the path as plain text), but the temp file is never removed
afterwards. Each paste creates a new modlens-dsh-paste-<random>/paste.<ext>
directory, and these accumulate indefinitely — they survive the read, the
session, and dsh restarts.

The exact command

Not applicable — no command fails; this is about the dsh web paste-to-path flow
(paste an image into the composer under a text-only model). The files appear
under the system temp directory, e.g.
C:\Users\<user>\AppData\Local\Temp\modlens-dsh-paste-XXXX\paste.png.

The full error

None — nothing errors; the problem is disk accumulation over time.

Harness and environment

• Harness: DeepSeek Harness (dsh), web profile, modlens installed as the native
  plugin (@liustack/modlens@3.17.2)
• Provider: openai (Qwen-compatible endpoint), but the leak happens before any
  provider is involved
• modlens --version: 3.17.2
• node --version: v24.9.0
• OS: Windows (system temp = %LOCALAPPDATA%\Temp)

Expected

The paste artifact should be removed once it is no longer needed (for example
when the image has been read or the session ends), or stale
modlens-dsh-paste-* directories should be purged periodically. Note the
attachment route (pasting while a (modlens vision) variant is selected) does
not leave temp files behind after the read — paste-to-path should behave the
same.

Steps to reproduce

1. In the dsh web GUI select a plain text-only model (no (modlens vision)
   suffix).
2. Paste an image into the composer — the message receives a file path under
   %TEMP%\modlens-dsh-paste-XXXX\.
3. Let the image be read (or skip the read), then close the session and even
   restart dsh.
4. Open %TEMP% and confirm the modlens-dsh-paste-XXXX directory is still
   there.
5. Paste more images — one new directory per paste, each up to 25 MB.

[paicat1]

是的，建议作者把默认的临时文件存放位置设置在系统的下载文件夹，可以比较容易集中清理

[liustack]

Fixed in 3.18.1.

npx -y @deepseek-ai/dsh plugin --profile web add @liustack/modlens@3.18.1

The asymmetry you spotted was the whole clue. The attachment route deletes its file in a finally; the paste-to-path route cannot, because the path it returns is what goes into the composer, so the file has to outlive the response and survive until the model reads it. That is why only this half leaked, and why the answer could not simply be "delete it too".

Pastes now live under one directory of ours rather than loose in the system temp directory, and expired ones are swept at the next paste. No timer to own, nothing running while nobody is pasting, and the work lands at a moment that already costs a disk write.

Two limits, because one is not enough:

• A week. This is a proxy rather than a proof: the path leaves through the composer as plain text, so nothing in the plugin observes whether the draft holding it was sent, cleared, or abandoned. It errs long on purpose, because the two failures are not symmetric. Deleting too early breaks a draft someone is still writing and reads as a bug in the paste; deleting too late costs kilobytes in a directory the OS already collects.
• A gigabyte. One image may be 25 MB, and a week is long enough for a burst to reach many of them before any expires, so age alone would let a determined paster fill a disk. It removes oldest first, which is a worse rule than knowing what is still referenced, and the only one available.

Your suggestion of purging periodically is what this does, with the trigger being the next paste rather than a clock, so nothing runs on an idle machine.

Review turned up something your report did not ask about but is worth stating, since it changed the design. The store's path is predictable and the system temp directory is shared, so on a multi-user machine the name can be taken first. A symlink planted there would aim a recursive cleanup at whatever it points to. So the store is now treated as untrusted ground: the parent is resolved, the directory is created inside the resolved path, and then it is checked rather than assumed. A link, a file, or another user's directory is refused, and one that cannot be made private is refused rather than used, because what it holds is your images.

Thank you for the report. Naming the difference between the two routes is what made the cause obvious, and the reproduction and the expected behaviour were both already in it.