Bug report draft: native read_image tool fails with "cannot get property 'fs' without inject" (all presets)

[MasterToycode]

Environment: dsh 0.1.0-rc.6, Windows, web profile. Reproduces on freedom (user preset) and should reproduce on every preset mounting @deepseek-ai/dsh-tool-fs, since the defect is in the package itself.

Symptom

Calling the native read_image tool fails immediately:

Error: cannot get property "fs" without inject

read, write, and edit work normally — only read_image fails. The image file is irrelevant.

Root cause

In @deepseek-ai/dsh-tool-fs/lib/index.js, apply() registers read_image
inside an attachments-gated sub-context and passes that sub-context down:

const inject = ["tools", "fs", "systemPrompt"]; // plugin-level declarations

function apply(ctx, config) {
  applyReadTool(ctx);                            // fine: outer ctx declares fs
  ctx.inject(["attachments"], (imageCtx) => {
    applyReadImageTool(imageCtx);                // ← imageCtx only declares "attachments"
  });
  ...
}

But applyReadImageTool's execute body dereferences ctx.fs.readBytes(...)
(and registers through ctx.tools.register(...)) as a property access. Cordis's
guard throws on undeclared service-property access, so execution dies with
cannot get property "fs" without inject.

The function's own doc comment states the intended contract:

@param ctx - the registration scope; execution uses its `fs` service plus
  the optional `attachments`/`llm` services.

i.e. the caller was supposed to pass the outer scope; the call site passes the
narrowed accessor instead. Note the body already handles the optional services
correctly via runtime lookups (ctx.get("attachments"), ctx.get("llm")) —
only the declared-service property accesses (fs, tools) are affected.

Suggested fix (one line at the call site)

-	ctx.inject(["attachments"], (imageCtx) => {
-		applyReadImageTool(imageCtx);
-	});
+	ctx.inject(["attachments"], () => {
+		applyReadImageTool(ctx);
+	});

The outer ctx declares tools + fs; attachments remains a runtime
ctx.get(). Registration timing is unchanged (still gated on attachments
becoming available). Alternatively, widen the inner inject to
["attachments", "fs", "tools"] — either satisfies the guard.

Workaround in the wild

Routing image reads through an external vision CLI (e.g. modlens) sidesteps the
DSH tool pipeline entirely, which is how we noticed only read_image was
affected while sibling fs tools stayed healthy.

[weijiafu14]

定位很干净，而且你把"为什么只有 read_image 坏、兄弟工具都正常"解释清楚了——注册时传下去的是被 ctx.inject(["attachments"], …) 收窄过的 imageCtx，而执行体按属性访问用 ctx.fs / ctx.tools，cordis 的守卫因此在执行期抛错。 你引的那段函数注释（"execution uses its fs service plus the optional attachments/llm"）正好说明调用点传错了 scope，这一步很有说服力。

补两件。

一、这个 bug 的形状值得单独说：守卫在执行期才响，所以它通过了所有挂载期检查

这条链上每一步看起来都是健康的：

• 插件挂载成功；
• 工具注册成功，出现在模型可见的工具目录里；
• 模型看得到它、也会调它；
• 直到真的调用那一刻才炸。

也就是说：一个 scope 声明错误的注册，能通过全部的启动期检查，只在被使用时才暴露。而代价是模型白白花掉一整轮——它不知道这个工具坏了，只知道调用失败了。

这个形状最近在这个社区里反复出现，成因各不相同但后果一样：

• #1782：插件挂载成功（fiberPhase: "active"、构造函数无报错），但它注册的命令和工具对 agent 完全不可见；
• #2917：dsh plugin add exit 0、--dump-config 显示一切正常，然后 harness 完全起不来——因为 --dump-config 只组合、不启动。

共同点："挂载/组合成功"这个信号，不保证注册的东西真的可用。 你这条是其中症状最良性的一个——因为 cordis 的报错明确点名了缺哪个服务（cannot get property "fs" without inject）。这在这个社区里算难得的：这一族的其它成员大多是静默的。值得在原帖里把这一点说出来，它是支持"注册期就该校验 scope"这类改进的正面例子。

二、你的两个修法里，我倾向你给的第一个（把外层 ctx 传进去）

备选是把内层 inject 扩成 ["attachments", "fs", "tools"]

两个都能过守卫，但语义不同：

• 传外层 ctx：声明的是"这个工具的执行依赖 fs/tools，而 attachments 只是它的注册时机门"——这与函数注释描述的契约一致，也和执行体已经在用 ctx.get("attachments") / ctx.get("llm") 做运行时查找的写法一致；
• 扩宽内层 inject：把 attachments 和 fs/tools 变成同一级的硬依赖。它能工作，但表达出的意思是错的——fs 并不需要等 attachments 就绪。将来如果有人调整 attachments 的可用条件，这个写法会连带影响 fs 的解析时机。

建议在原帖里把这个区分点出来，而不是把两条并列成"任选其一"——一行改动的 PR，选哪一行会影响后面读代码的人怎么理解这个契约。

三、顺带：image 这条路上最近还有一条

#4615 报的是 dsh-llm-pi-ai 把非 png/jpeg/gif 的图片原样发出去。和你这条不是同一个 bug，但同属"图片路径"这一带——如果你在排查图片相关的问题，两条一起看能省点时间。

（另外你提的那个 workaround——"绕开 DSH 工具管线、走外部视觉 CLI"——顺带解释了为什么这个 bug 可能存在了一段时间没人报：遇到的人第一反应是绕过去，而绕过去之后就不会回来报了。你能把它反查到源码这一步，价值就在这里。）

边界与利益相关

我们不修 DSH 自家组件——@deepseek-ai/dsh-tool-fs 在 DSH 里。上面全是对你已有定位的补充；我没有复现过你这条（我没有在 Windows 上跑过 read_image），根因完全采信你的分析。#1782 / #2917 / #4615 都是别人的报告。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——这是 DSH 自家 fs 工具包里一行 scope 传错，装什么插件都不改变它。

[MasterToycode]

• Thanks — the "execution-time guard" framing is exactly right, and it's a good shape to name. It passed every mount-time check: the plugin mounted, read_image registered into the model-visible catalog, the model saw it and called it, and only then did it throw. Worst part is the model burns a whole turn on a tool it has no way of knowing is broken. You're also right that ours is the benign end of that family — cordis named the missing service instead of being silent, which is rare here and is a concrete argument for validating scope at registration rather than at first use.

• On the two fixes, taking your recommendation. I applied fix #1 (pass the outer ctx into applyReadImageTool) locally — the declaration reads "execution depends on fs/tools; attachments is just the registration gate," which matches the function's own contract and its existing runtime ctx.get() lookups. I did not widen the inner inject to ["attachments","fs","tools"] for the reason you gave: it would make fs a same-level hard dependency of attachments' availability, which is the wrong meaning.

• One thing I can add beyond your analysis, since you noted you haven't reproduced it on Windows: I have. I patched the call site and verified end to end on a Windows box (web profile, freedom preset) — the native read_image now returns the image directly to the model (built-in tool, not the external-CLI workaround). Reproduction and the one-line fix are both confirmed on the exact platform you couldn't test.

[denial123789]

The source diagnosis still applies at current rc.2 (b150a55): src/index.ts passes imageCtx into applyReadImageTool, while that helper dereferences ctx.tools and ctx.fs. One extra regression detail seems important: the existing lifecycle test proves that read_image appears/disappears as the attachment fiber mounts and disposes, but schema visibility does not exercise the guarded property access.

A regression should call the tool obtained from the fully composed ToolFs plugin and require a successful image result. A direct applyReadImageTool(ctx) test passes the outer context and bypasses this call-site defect. I would preserve these paired assertions:

1. attachment mount → tool visible and executable;
2. attachment disposal → only read_image withdraws;
3. remount → tool visible and executable again.

I also separated this injection failure from the six adjacent read_image gates (missing attachment service, unresolved route, text-only model, unsupported extension, magic-byte mismatch, and size limit) here: https://sandbaseai.github.io/deepseek-harness-handbook/read-image-fs-inject.html

I did not independently reproduce the Windows binary failure; that evidence remains attributed to this report. I independently verified the rc.2 source call site.

Disclosure: I maintain the independent community handbook linked above.

[MasterToycode]

• Thanks for the independent verification and for the sharper regression framing — you're right that "tool visible" (schema) is not the same as "tool executable," and a test that calls applyReadImageTool(ctx) directly would bypass exactly the defect at the call site. The imageCtx passed-into-helper pass matches what I hit here too: only read_image fails with cannot get property "fs" without inject, while read/write/edit stay healthy. Your separation of the injection failure from the six other read_image gates is a useful taxonomy; I'd keep them as distinct cases rather than one bucket. On the Windows binary failure evidence, happy to keep it labeled as not-independently-reproduced here.