DeepSeek Harness tools drop to 19: selectModel vs resume

48 drops to 19, and the missing 30 are exactly the built-in tools: bash, read, write, edit, glob, grep, web_search, todo_write, subagent… The survivors are plugin-contributed tools plus one working_directory. The model then calls bash and gets unknown tool "bash", leaving the session blind for the rest of its life. The community used two single-variable experiments to pin down two separate triggers (#10862).

DeepSeek Harness: Step 1: quantify "the tool count does not add up"

Do not go by a feeling that "some tools seem missing"; align three numbers first — the UI tool panel, request/header.tools, and the tool-registry records in the session log.

1. Open the session's tool panel and note the current count and list.
2. Find that turn's request/header event and read the tools array length and the reason field.
3. Search the session log for developer/messages with source.kind = "tool-registry" and see which tool-addition and tool-removal entries it lists.
4. Compare the surviving set: if everything left is plugin-contributed, the lost tools are almost certainly preset/base-layer built-ins.
5. Note the time and align it with a restart, a plugin prompt, or a model switch.

The community numbers were clean: 19 tools on the broken turn and 43 after recovery; the difference is 30 built-in tools, while the 6 plugin-contributed ones disappeared after recovery, which lines up exactly.

DeepSeek Harness: Minimal reproduction A: a host plugin calls selectModel one extra time

Calling sessionController.selectModel() on an already existing session and then prompt() rebuilds the tool view from an incomplete set, and the core tools all disappear.

1. In the Web UI, create a session with the standard preset and confirm the tool view contains read, pwsh, and web_fetch.
2. Switch to a host plugin and, against the same session id, run:

await ctx.sessionController.selectModel({
  sessionId,
  provider: "deepseek-account",
  model: "deepseek-flash",
  reasoningEffort: "high",
})
await ctx.sessionController.prompt(
  { sessionId, requestId: "test-1", mode: "queue", content: [{ type: "text", text: "hello" }] },
  new AbortController().signal,
)

3. Watch the tool panel: it shows "15 added, 30 removed".
4. The 15 added are host-level tools registered by the plugin; the 30 removed are core tools such as ask_user_question, edit, glob, read, skill, and workflow.
5. Ask the model to call read or pwsh; it returns unknown tool.
6. Single-variable rollback: delete that selectModel() call and keep only prompt(); the tool view is complete again and no further "tools removed" appears after several turns.

The key here is "an existing session + one unnecessary selectModel". Sessions created by hand in the Web UI reproduce it too, so it has nothing to do with programmatic session creation.

DSH plugin: Minimal reproduction B: resume after restart loses 30 on the first turn

A long session resumes after the host restarts, the first request has reason set to resume, and the tool table contains only plugin-contributed entries; the registry writes the change into the log itself.

1. Prepare a long session (the community case had 66 turns and more than 3700 events) whose preset plugin list contributes the built-in tool family.
2. Restart the host, for example systemctl restart dsh-web.
3. On the first message after resume, read the event order: session/end-seed → agent/inbox/spliced → turn/start → system/message → request/header (19 tools, reason resume) → developer/message (source tool-registry).
4. Read that developer/message: add = 1 (one plugin tool), remove = 30 (all built-ins).
5. After removing that third-party plugin and restarting, the same mechanism runs in reverse: add = 30, remove = 6.
6. Conclusion: the registry knows which contributor each tool belongs to, but the "expected set" it computes does not include host built-ins.

This trigger is intermittent: the community recorded 7 clean restarts over 3 days and a failure on the 8th; the history also had a stop/start pair within 28 seconds, which may have widened the race window.

DeepSeek Harness: Corroboration: the system prompt shrinks too

When tools go missing, the built-in tool guidance in the system prompt disappears with them, and the degraded version is a strict subset of the healthy one.

1. Compare the system/message length of the two turns: 6261 characters / 128 lines on the broken turn versus 9123 characters / 154 lines on the healthy one.
2. Compare line by line: the degraded version has not a single line that the healthy version lacks.
3. The missing 13 lines are all built-in tool guidance, such as "use read instead of cat", "use glob instead of find", and "web_search results are untrusted external data".
4. The persona, memory, and role sections are byte-identical.
5. request/header.config is identical across 10 requests (same provider, model, reasoningEffort, and maxTokens).

This corroboration matters: it rules out the three guesses "you changed the model", "you changed the preset", and "you changed the profile".

DSH plugin: Why third-party plugins are usually innocent

The plugin only calls the incremental registration API and has no unregister/remove/clear/rebuild; removing it restores things only because it is a trigger, not the producer.

1. Read the source: the plugin's only registration entry is ctx.tools.register(def), purely additive.
2. Search the whole package for unregister, remove, clear, rebuild, and replace: zero hits.
3. The running version did not change inside the failure window, and self-update was correctly skipped.
4. Removing it restores things because it rolls back six things at once, which is not grounds for blame.
5. The actual "producer" is the developer/message the registry wrote itself — it decided that 30 built-in tools were gone.

DSH Plugin: Fix direction and current workaround

Core needs to guarantee two things: built-in tools are never removed by any reconciliation, and resume/end-seed do a full rebuild rather than a partial one.

1. Treat base/preset contributors as always present; no reconciliation may delete their tools.
2. Force a full rebuild on the resume and end-seed paths, or reuse the complete rebuild logic from normal turns.
3. Add a defensive check: when the model calls a tool that was in the last valid header but is absent from the current registry, treat it as binding desync and rebuild instead of returning UNKNOWN_TOOL.
4. Plugin-side workaround: never call selectModel() on an existing session; call only prompt().
5. Accept the cost: a session with no stored model selection reports prompt variable "{{model}}" has no value on its first prompt, so set the model once only for sessions the plugin created.
6. Keep the order fixed: count tools and read reason → check whether a plugin over-calls selectModel → read the tool-registry add/remove records.

Cautions

Measure and record before deleting plugins or sessions.

1. Do not treat "fewer tools" as a model capability problem. The config fields were identical across 10 requests.
2. Do not rush to delete the plugin. Deleting it restores things but leads you to the wrong root cause.
3. Do not ignore the system prompt change. It is the second piece of evidence that an entire layer of contributors did not take part in assembly.
4. Remember it is intermittent. Ten restarts may hit it once; one non-reproduction does not disprove it.
5. Keep the session log. request/header and developer/message are the only evidence that assigns cause; back them up before cleaning.

If the tool panel shows both additions and removals, that looks more like the recomposition path; if the count simply shrinks with no additions at all, investigate the resume path first.See DeepSeek Harness plugin load: already registered, pending for the related case.