DeepSeek Harness "unknown tool": null wipes tool call id

When DeepSeek Harness reports unknown tool "" and every tool call fails while the model spins for a few steps, the stream translator has overwritten the tool call identity with an empty value: after the first frame supplies id and name, the provider sends a delta carrying an explicit null, and the !== undefined check writes that null over the captured identity. Nothing is corrupted and no config is lost — switching to a provider that does not send explicit null deltas restores tool calls immediately.

What the DeepSeek Harness unknown tool error looks like

The shape is fixed: the log shows [tool/call] {"callId":"","name":""} followed by unknown tool "". A user hit this in the wild (see the discussion), and the symptoms were:

1. The model issues a tool call normally, but the printed request has empty callId and name strings;
2. The runtime finds no tool named "" and rejects execution with unknown tool "";
3. The model never receives a usable result, retries for a few steps and exits with zero output for the turn;
4. Every tool call under that provider fails together — it is not one broken plugin.

This is why the error is easy to misread: the text points at "tool does not exist", which looks like a missing plugin or a typo, while the plugin is perfectly fine. What was dropped is the identity carried by the call, not the tool (see Discussion #4671).

Why a DSH plugin's tool call identity gets overwritten by null

The root cause sits in the SSE translation layer, which treats "field present" and "field has a value" as the same thing. Streaming responses arrive frame by frame: the first frame carries the full id and name, and later deltas carry only what changed. After checking the source, the community located it in packages/llm/llm-deepseek/src/translate.ts. The chain is:

1. The translator accumulates tool call identity and uses !== undefined to decide whether a frame should update the fields;
2. The provider sends null rather than omitting the field, and null !== undefined is true, so the update runs;
3. The id and name captured in the first frame are overwritten with empty values, which is exactly the {"callId":"","name":""} in the log;
4. The empty name is the fatal part: an empty name makes the tool unresolvable, while an empty id only makes the call hard to correlate (source: Discussion #4671).

The correct check updates a field only when it has a real value, treating both undefined and null as absent. The community branch fix/tool-call-null-delta-identity changes exactly that, and a reference implementation exists in Jstn-1g/reference/discussion-4671-sse-null-identity (commit 138691e0). Neither is merged yet.

How to work around a DSH plugin unknown tool loop, and where the fix stands

Until the fix lands upstream, work around it by avoiding the trigger: change provider or model, or roll back the build. In order of how quickly you can do it:

1. Switch to a provider or model that does not send explicit null deltas — the fastest route, effective in the same session;
2. Roll back to the DeepSeek Harness build you used before the regression;
3. Keep the full log while diagnosing: whether callId / name on the [tool/call] line are empty is the only reliable way to tell "the tool really is missing" from "the identity was overwritten";
4. If you need to add or roll back a plugin to compare, manage installed plugins from Settings → Plugin Marketplace; the community marketplace for this project is DSH Plugin Hub;
5. On the fix: the branch names the exact change (the check condition), but it is still waiting to be merged, so do not expect the loop to disappear before you upgrade to a build that includes it.

DSH plugin troubleshooting notes

Separate "the tool is missing" from "the call identity was overwritten" before touching anything: the first means changing a DeepSeek Harness plugin setup, the second only means switching provider or rolling back. Three traps to avoid:

1. Do not treat unknown tool "" as an installation problem: reinstalling the plugin changes nothing, because the overwritten value is runtime state, not the plugin package.
2. This is not a model-capability issue, so prompt tweaks will not help: the null delta overwrites the identity no matter how the prompt is written.
3. More model-related failures are collected in DeepSeek Harness model errors: connection failures, missing model lists and configuration.

Sources: Discussion #161, Discussion #4671