[Bug] Local file plugins in a profile make every official DeepSeek request fail with REQUEST_EXTENSION (profile package.json must declare non-empty name and version)

[Dapan-panda]

Bug report (issues are disabled on this repo, posting here per README)

Describe the bug

Adding a local file-path plugin to a profile (cordis.patch.yml insert with an absolute .ts path) makes every request to the official DeepSeek provider fail before any HTTP is sent with DeepSeek request extension preparation failed / REQUEST_EXTENSION. The plugin itself loads fine; the failure happens in the default-on plugin-package-inventory-deepseek request extension.

To reproduce

1. Run from source or npm: pnpm dsh web (dsh 0.1.3-alpha.1, commit d347e70390). Profile root: ~/.dsh/profiles/web/.

2. Add a local file plugin in ~/.dsh/profiles/web/cordis.patch.yml:

   - insert:
       - id: my-tool
         name: '/Users/<you>/.dsh/profiles/web/plugins/my-tool.ts'

   (plugins/ has no package.json of its own.)

3. Start a session with the official DeepSeek model (e.g. deepseek-v4-flash) and send any message. The UI shows 本轮运行失败 / DeepSeek request extension preparation failed / REQUEST_EXTENSION immediately — 0 LLM time, no HTTP request observed.

Root cause

plugin-package-inventory-deepseek's PackageIdentityResolver.resolve (packages/llm/plugin-package-inventory-deepseek/src/index.ts:104) resolves every active loader entry on each request. For a file-path module it calls nearestManifest() (index.ts:86), which walks up from the plugin file to the nearest package.json — here ~/.dsh/profiles/web/package.json, the container package.json generated by the profile bootstrap with name/private but no version. identityFromManifest() (index.ts:61) then throws plugin-package-inventory-deepseek: <path> must declare non-empty name and version, which surfaces as REQUEST_EXTENSION. The real cause (with the offending path) is not visible in the UI or session log — only via server-side instrumentation.

The same version-less generated container exists for headless profiles (~/.dsh/profiles/{web,headless}/package.json), so any file-path plugin there hits the same path. Bundled plugins are unaffected because they are bare-package entries that resolve to real packages.

Expected behavior

Local file plugins that happen to sit under a profile container package.json should not fail every request. Options: (a) generate the container package.json with a version, or (b) treat a nearest manifest without version as an anonymous loose module when allowAnonymous is set (skip it) instead of throwing.

Workaround

Add "version": "0.1.0" to the profile package.json, or place file plugins in a subdirectory with its own package.json (name + version). Both fixes verified locally.

Environment: macOS, Node v24, dsh 0.1.3-alpha.1 (source HEAD d347e70390); profile bundles: dsh-base + dsh-web-app + a third-party tgz bundle (dsh-worktable 0.2.3).

[Dapan-panda]

中文摘要

问题:在 profile 的 cordis.patch.yml 里用文件路径方式插入本地插件(如 plugins/my-tool.ts)后,每次调用官方 DeepSeek 模型都会在发出 HTTP 请求前就失败,报 DeepSeek request extension preparation failed (REQUEST_EXTENSION),UI 显示"本轮运行失败"。

原因:每次请求前,默认开启的 plugin-package-inventory-deepseek 扩展会把所有活动插件解析为"包身份"上报模型。对文件型插件它会向上查找最近的 package.json,命中 dsh 自动生成的 profile 容器文件(~/.dsh/profiles/web/package.json)——该文件只有 name 没有 version,解析器于是抛错,导致整个请求失败。

建议修复:① 生成 profile 容器 package.json 时补上 version;② 或将"缺少 version 的最近 manifest"视为匿名本地模块跳过,而不是抛错。

临时绕过:给 profile 的 package.json 添加 "version": "0.1.0",或把本地插件放进带自身 package.json(含 name 与 version)的子目录。

[argszero]

Confirmed on master d347e70390 — your root cause is accurate, and this is the 6th report of a known family, which makes the fix direction clearer than a one-off patch. Details:

Your anchors check out (line numbers drift slightly in master):

• packages/llm/plugin-package-inventory-deepseek/src/index.ts — identityFromManifest (:61-70) throws must declare non-empty name and version; nearestManifest (:82-95) walks to the nearest package.json (your profile container); resolve (~:100-130) calls them per active Loader entry.
• The subtlety that makes your case bite: allowAnonymous (the packageName === undefined branch) was designed to tolerate anonymous loose modules (manifest with no name → return undefined = no identity). But your profile container has a name and no version — so it isn't treated as anonymous, and the throw fires.

Known family (5 prior threads, same root): #5172 / #5173 / #5196 / #5439 / #5683 — plugin-package-inventory-deepseek's fail-closed per-entry throw inside the request-extension prepare (Promise.all across api-extensions) kills the whole request. Two aggravators shared by all 6: (a) the throw happens before the cache set in resolve, so it is never memoized and re-fires on every request (your "every official request fails" is the exact signature); (b) the surfaced error (REQUEST_EXTENSION) doesn't name the offending entry/path — only server-side instrumentation shows it (your observability point is also a known gap).

On your two proposed fixes:

• ② (treat a version-less nearest manifest as no-identity for file-path entries) is the robust one and matches the family consensus (per-entry degrade to undefined, never throw the whole prepare). Fixing only the throw-site to tolerate a named-but-version-less manifest under allowAnonymous is a 2-3 line change plus a regression test.
• ① (bootstrap emits version in the generated container) helps new profiles but is insufficient alone: existing generated containers persist on disk, the headless profile has the same shape, and any other version-less container a user's file path happens to sit under would keep throwing. Treat it as a secondary hygiene fix, not the gate.

Plugin-surface note: this gap is in the core request-extension prep (it consumes Loader entries); the file-path plugin is an innocent victim — a local plugin must never be able to break every official request. Worth archiving as an upstream-fix candidate with the two-line degrade direction. If you want a workaround today: give your plugins/ directory (or the profile root) a real package.json with a version, or mount the local plugin as a bare package — either bypasses the version-less-container throw.