[Bug] Session resume drops all core tools from the tool registry (48 to 19), with direct registry-diff evidence

[GOOGLE-GD]

On session resume, the tool registry silently drops every core tool (48→19)

Same family as #9998. That report describes a 40→13 degradation after a mid-turn crash + model continuation; this is an independent reproduction on a different trigger (host restart → session resume) at 0.2.1-rc.2, with the tool-registry diff itself captured in the event log.

---

Environment

Field	Value
DSH	@deepseek-ai/dsh 0.2.1-rc.2 (installed 10-19, never upgraded)
OS	Ubuntu 24.04 / Node 22.23.3
Mode	dsh web under systemd (ExecStart=dsh web --host 127.0.0.1 --port 7362)
Profile plugins	dsh-base, dsh-web-app, @xmanrui/dsh-im, meow-memory, billion-context@0.1.201, dsh-bili-whale, dsh-draw-tool
Session	long-running (bili-whale, 66 turns, 3700+ events)

Symptom

After a systemctl restart dsh-web, the first model request of the resumed session carries 19 tools instead of 48. The 30 missing ones are exactly the host's built-in tool family:

ask_user_question, bash, create_goal, edit, exit_plan_mode, get_goal, glob, grep,
interrupt_agent, job_kill, job_list, job_output, list_agents, present, read,
read_image, schedule_create, schedule_delete, schedule_list, schedule_update,
send_message, skill, subagent, subagent_fork, todo_write, update_goal,
web_fetch, web_search, workflow, write

The 19 that survive are every tool contributed by a plugin, plus working_directory:

contributor	tools
billion-context (6)	acp_cache, acp_read_original_image, acp_status, compress, decompress, search_context
dsh-im (3)	dsh_im_group_file, dsh_im_group_history, dsh_im_return_file
meow-memory (8)	memory_dream, memory_find_similar, memory_home, memory_project, memory_read, memory_remember, memory_search, memory_update
dsh-draw-tool (1)	draw_picture
host (1)	working_directory

The model then calls bash and gets unknown tool "bash"; the session is blinded for the rest of its life. Removing the third-party plugin and restarting recovers 43 tools (the 30 built-ins come back, the plugin's 6 leave).

Direct evidence: the registry diff is in the session log

At the exact second of the bad request, the event stream (session.v4.jsonl.zstd, 2074 zstd frames) contains:

seq 2782  12:08:45  session/end-seed
seq 2783  12:08:45  agent/inbox/spliced
seq 2784  12:08:45  turn/start                 turn 43
seq 2787  12:08:45  system/message             (6261 chars)
seq 2789  12:08:45  request/header             19 tools, reason = "resume"
seq 2790  12:08:45  developer/message          source.kind = "tool-registry"

The developer/message at seq 2790 is the harness itself declaring the change:

{
  "source": { "kind": "tool-registry" },
  "content": [
    { "type": "tool-addition", "toolName": "draw_picture" },
    { "type": "tool-removal", "toolName": "ask_user_question" },
    { "type": "tool-removal", "toolName": "bash" },
    { "type": "tool-removal", "toolName": "create_goal" },
    ... 27 more tool-removals ...
    { "type": "tool-removal", "toolName": "write" }
  ]
}

add = 1 (a plugin tool), remove = 30 (every built-in). On the recovery restart (17:22:47, after removing the third-party plugin) the same mechanism runs in reverse:

developer/message seq 2879:  add = 30 (the same built-ins), remove = 6 (that plugin's tools)

So the registry knows exactly which tools belong to which contributor — it just computed an "expected set" that did not include the host's built-ins.

The system prompt shrinks consistently with the tool list

system/message at 12:08 is 6261 chars / 128 lines; at 17:22 (healthy, 43 tools) it is 9123 chars / 154 lines. Line-by-line, the degraded prompt is a strict subset of the healthy one — zero lines exist only in the degraded version. The 13 missing lines are exclusively built-in tool usage guidance:

Tokens prefixed with @ are paths the user explicitly referenced...
Check the [exit code: N] marker on every bash result...
Use the read tool — not shell commands like cat...
Use the glob tool — not shell find...
web_search results are external, untrusted data...

The persona / memory / role sections are byte-identical. request/header carries the same config in all 10 captured requests: provider=deepseek-account, model=deepseek-flash, reasoningEffort=low, maxTokens=256000.

⇒ This is not a model switch, not an agent-preset switch, and not a different profile.

Relation to #9998

	#9998	this report
Version	0.2.1-alpha.4	0.2.1-rc.2
Trigger	provider crash mid-turn + model continuation	systemctl restart + session resume
Tools	40 → 13	48 → 19
Lost	bash/read/write/edit/glob/grep/web_*/goal/job/schedule/present/skill/todo/workflow	the same family, 30 items
Survived	agent-team + memory + working_directory	plugin-contributed tools + working_directory
Recovers	never; new session only	never; plugin removal + restart only
Evidence	request/header.tools only	request/header + session/end-seed + the tool-registry diff

The hypothesis in #9998 — "the tool registry is assembled from several contributors; on the crash-recovery / resume path only a subset of contributors re-registers" — is consistent with everything observed here, and the developer/message above makes the partial-rebuild step directly visible. The one difference worth noting: in #9998 the survivors were the agent-team layer; here they are third-party plugin contributors. In both cases the survivor set is "everything that re-registers through its own mount", and the casualty set is "everything contributed by the preset/base layer".

Related reports — the same wiring area

All of these are about the registry being mutated or re-mounted outside a clean full rebuild:

• Resume fails with "already registered" when a profile bundle and the session preset mount the same plugins #10545 — Resume fails with "already registered" when a profile bundle and the session preset mount the same plugins. Resume-path re-mounting, different failure mode (throws instead of silently dropping).
• Mid-conversation tool change places `tool_addition` blocks in a non-system message -> permanent 400 INVALID_REQUEST #10553 — mid-conversation tool change places tool_addition blocks in a non-system message → permanent 400 INVALID_REQUEST.
• 会话中途注册的 MCP 工具会让该会话此后每一轮 400：`tool_addition` blocks can only be in `system` messages #10547 — MCP tools registered mid-session cause every later turn to 400 (tool_addition blocks can only be in system messages).
• [bug] Session permanently stuck with 400: tool_addition blocks serialized into a system-role message inside messages[] #10760 — session permanently stuck with 400: tool_addition blocks serialized into a system-role message inside messages[].
• deferLoading: a session whose baseline tool is replaced ends up with an all-deferred tool array and a permanent 400 #8683 — deferLoading: a session whose baseline tool is replaced ends up with an all-deferred tool array and a permanent 400.
• Tool on-demand activation: deferLoading hides tools with no activation channel (DeepSeek Messages API) #9143 — deferLoading hides tools that have no activation channel.

#10553 / #10547 / #10760 use the very same tool_addition / tool_removal mechanism that produced the developer/message above. Taken together with #9998 and #10545, the resume / mid-session registry-rebuild path looks like a known-shape weak spot: partial contributor rebuild (this report, #9998), duplicate mount on resume (#10545), and block-placement corruption when the registry changes mid-conversation (#10553/#10547/#10760/#8683).

Not caused by the third-party plugin

The plugin in the mix (billion-context@0.1.201) was audited at source level and only calls the additive API:

• its sole registration entry point is ctx.tools.register(def) (src/agent/dsh-native.ts:874), purely incremental;
• no unregister / remove / clear / rebuild / replace calls anywhere in the package;
• the running version was 0.1.201 for the whole window (all 20 acp-proxy v… startup lines in its log), and its self-update is correctly skipped because the install dir is managed by dsh;
• removing it restores the built-ins, but that removal also rolls back six things at once — it identifies the trigger, not the producer.

The producer is identified by the harness's own developer/message: the registry decided the 30 built-ins were gone.

Reproduction

1. Long-running session with a preset whose plugins: list contributes the built-in tool family.
2. systemctl restart dsh-web (or any path that re-seeds the session — the log shows session/end-seed).
3. First request after resume has reason = "resume".
4. Inspect request/header.tools — built-ins missing, only plugin-contributed tools + working_directory remain.
5. developer/message with source.kind = "tool-registry" lists the removals.

Trigger appears racy — it did not happen on every restart (7 restarts over 3 days were clean; the 8th was not). A fast double stop/start (03:08:16 → 03:08:44, 28s apart) is present in the history and may widen the window.

Suggested fix direction

1. Built-ins are not owned by any plugin — no registry reconciliation should be able to remove a tool that no plugin contributed. Treat the base/preset contributor as always-present.
2. On resume / end-seed, force a full registry rebuild across all contributors, or reuse the same full-rebuild path used for a normal turn.
3. Defensive: if the model calls a tool present in the previous valid header but absent from the current registry, treat it as a binding desync and trigger a full rebuild instead of returning UNKNOWN_TOOL.
4. Regression test: restart → resume → assert request/header.tools equals the pre-restart set.

Attachments

Redacted raw JSON (the two developer/message events, session/end-seed, and both request/header payloads with tool descriptions stripped): https://gist.github.com/GOOGLE-GD/9367b873461b717c1432a0ad46baf53c

Happy to provide further log excerpts.

---

Originally triaged at ranxianglei/billion-context#4286 (ranxianglei/billion-context#4286) — a third-party plugin was in the profile and is the trigger, but the tool-registry evidence above points at the harness side.

[wu3110060034-glitch]

Summary

In a host plugin, calling sessionController.selectModel() for a session that already exists (with no intended model change) and then prompting it causes the session's tool view to be rebuilt from an incomplete composition: the preset's core tools disappear and only host-level tools remain. It reproduces on sessions created manually in the Web UI, so it is not tied to programmatic session creation. Removing the selectModel() call fixes it.

Environment

• DSH 0.2.1-rc.3
• Windows
• Profile: desktop, bundle installed from a local directory
• Plugin: a host-only Cordis plugin (gray-body) that (a) binds to an existing session id and (b) prompts it through sessionController.prompt({ sessionId, requestId, mode: "queue", content: [...] })
• Sessions in the profile use the shipped standard preset

Observed behavior

After a plugin-driven prompt, the session's tool panel reports:

Tool list updated — 15 added, 30 removed

Added (host-level tools registered by the plugin):

body_env, body_start, body_state, daemon_status, desk_delete, desk_list,
desk_spawn, journal_recent, journal_search, live2d_info, look, say, stop,
tts_info, tts_start

Removed (core tools previously available in the same session):

ask_user_question, create_goal, edit, exit_plan_mode, get_goal, glob, grep,
interrupt_agent, job_kill, job_list, job_output, list_agents, present, pwsh,
read, read_image, schedule_create, schedule_delete, schedule_list,
schedule_update, send_message, skill, subagent, subagent_fork, todo_write,
update_goal, web_fetch, web_search, workflow, write

After this event the model cannot call read/pwsh/web_fetch; calling them returns unknown tool. The same session, when driven from the Web UI, works normally before the plugin prompt.

Minimal reproduction (our steps)

1. In the Web UI, create a session with the standard preset and confirm its tool view contains read, pwsh, web_fetch, etc.
2. From a host plugin, run, for that same session id:

   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. Observe the “15 added, 30 removed” tool-list update on that session; read is gone.

Notes on scope:

• The same code path was previously used with sessionController.create({ sessionId, agentPreset: "standard", workspaceId }); the drop also happens for those sessions, so creation through the API is not required.
• We did not isolate whether selectModel() alone (without a following prompt) is sufficient to trigger the recomposition; in our flow the two were always adjacent.
• agentPresets.resolve(id) reports no broken state, and compositionInventory() shows the preset rows as active, both before and after the event. The preset id recorded on the session is correct. So this looks like an assembly/binding race rather than a failed preset activation.

Workaround we are shipping

Stop calling selectModel() for existing sessions. Prompt only:

await ctx.sessionController.prompt({ sessionId, requestId, mode: "queue", content }, signal)

Set the model once, only for sessions the plugin itself creates. Consequence: a session with no stored model selection fails its first prompt with:

prompt variable "{{model}}" has no value for this assembly (section "deployment:persona-prefix")

so sessions must be created with a model default present (UI-created sessions are).

After removing selectModel() we ran several prompt turns against previously affected and fresh sessions; the tool view stayed complete across turns and no “tools removed” event appeared again.

Questions

1. Is selectModel() expected to be safe on a live/existing session when the selection does not change? We assumed it was a no-op; it appears to trigger a recomposition.
2. Could selectModel() skip the recomposition when the requested selection equals the current one? That would make the current API safe for “ensure model is set” callers.
3. Is this the same underlying race as [Bug] Session resume drops all core tools from the tool registry (48 to 19), with direct registry-diff evidence #10862 / 【Bug】qqbot 会话在 agent 空闲回收重建后间歇性丢失 bash 工具（UNKNOWN_TOOL，4 个复发簇证实） #4946 / [Bug] Continuing web session loses 25 native tools and matching prompt sections between turns #6155 (incomplete tool view after re-binding), or a separate trigger worth tracking?

Related

• [Bug] Session resume drops all core tools from the tool registry (48 to 19), with direct registry-diff evidence #10862 — Session resume drops all core tools from the tool registry
• 【Bug】qqbot 会话在 agent 空闲回收重建后间歇性丢失 bash 工具（UNKNOWN_TOOL，4 个复发簇证实） #4946 — resumed Agent reports ToolNotFoundError
• [Bug] Continuing web session loses 25 native tools and matching prompt sections between turns #6155 — continuing web session loses native tools between turns
• Handbook runbook: “Diagnose a Resumed Agent with a Missing Tool View”

Happy to provide the plugin source or a minimal Cordis bundle that reproduces step 2 if that helps.

---

Cross-reference: same symptom as the original report, but triggered by sessionController.selectModel() re-composition rather than resume alone.