Tools registered after a plugin is installed mid-session: present in request/header but the model callable list omits them

[cinast]

Draft discussion → deepseek-ai/deepseek-harness (Discussions)

Category: Q&A (or Ideas if Q&A feels wrong — there is no Bug category)

Title: Tools registered after a plugin is installed mid-session: present in request/header but the model's callable list omits them

---

What I observed

DSH 0.2.0-rc.2, dsh web, profile web, Windows 11 x64, Node v24.18.1.

Two cross-session plugins are installed in the profile (dsh-call-session 0.1.10, dsh-conversation-link 0.4.3, both in dsh.profile.bundles). Both are mounted — dsh-conversation-link writes its own mount.json:

{ "mountedAt": "2026-10-24T13:26:34.368Z", "pid": 28556, "node": "v24.18.1", "tools": 7, "plugin": "dsh-conversation-link" }

The pid matches the process that owns :3080.

In this long-lived session (created 2026-10-22, ~110 turns), the last request/header recorded in the session log contains 107 tools, including all 16 cross-session ones:

board_clear board_list board_post
conversation_link conversation_list conversation_rule conversation_send
conversation_spawn conversation_status conversation_unlink
session_call session_create session_inspect session_query session_repair session_scan

Yet the assistant cannot invoke them: requests to call conversation_send / session_call / board_post resolve to a different tool (a shell tool), as if those names were not in the callable set. Meanwhile a freshly created session in the same host used conversation_link and conversation_send successfully on its first turn (they appear as ordinary tool/call records in its log).

So the same host, same plugins, same 107-tool payload: new session → callable, this session → not callable.

What the session log says about how they arrived

tool-registry developer events in this session:

• turn 61 (2026-10-24T13:09:14Z): one tool-addition batch containing board_clear, board_list, board_post, session_call, session_create, session_query;
• turn 73: session_inspect, session_repair, session_scan;
• no event ever mentions conversation_* — although dsh-conversation-link was mounted at 13:01:43Z, i.e. before the turn-61 batch.

The same is true for another long-lived session in this machine (session-ca38567c, 85 turns): 0 tool-registry events total, and it also cannot see these tools.

The question

1. Is the model-facing tool list supposed to be derived from request/header? If yes, a tool present there should be callable, so the omission I hit is unexpected.
2. If instead the model-facing list is a projection of the tool registry (the tool-registry events), then: why is a plugin that mounts while the session is idle never reconciled into it? dsh-conversation-link was already mounted when turn 61 added call-session's tools, but its 7 tools were not included in that batch.
3. Is there a supported way to force a reconcile for an existing session (short of restarting the host, which I did — and it did not help: these tools were still missing from the callable list after a restart that mounted the plugins at boot).

Why it matters

Long-lived sessions are exactly the ones a user wants to reuse, and "install a plugin, then talk to an old conversation" silently produces a session that looks fully equipped (its payload lists the tools) but cannot use them. There is no user-visible symptom other than the model saying "I don't have that tool" — which reads like a model failure, not a harness one.

If this is expected behaviour, documenting it (e.g. "tools are bound at session start; open a new conversation after installing plugins") would already help.

Environment

• DSH 0.2.0-rc.2 (@deepseek-ai/dsh), installed app, dsh web --no-open
• profile ~/.dsh/profiles/web, plugins installed via dsh plugin --profile web add … (one file: tarball, one github: dep)
• session in question: session-1085f855-e84a-460a-9891-53a572de9372 (cwd …\deepseek-harness\default-workspace)

[dgesteves]

The model never sees the request/header list. request/header.tools records every active tool. What actually goes to DeepSeek is built from the session's tool history, and deepseek-flash declares toolUpdate: 'addition-only' (models.ts). On that route, any tool that wasn't in the session's declaration baseline goes out as defer_loading: true (content.ts L381-L411). It is only activated by a tool_addition reference, which the adapter sends as an inline role: "system" message with the mid-conversation-tool-changes-2026-07-01 beta (serialize.ts). A fresh session has those tools in its baseline, so they go out as plain declarations. That's the only difference in how the tools reach the model in your two sessions, so the deferred path is the one failing for you.

On 2 and 3:

• tool-registry messages aren't written when a plugin mounts. On each request the loop diffs that step's assembled tools against the previous request/header and appends the additions and removals (agent.ts L635-L648). If a header lists tools that no baseline or addition accounts for, snapshot() falls back to declaring that whole header normally (tool-history.ts L68-L72). So check which header first lists conversation_*, and its reason.
• A restart changes nothing. The resumed Agent starts from the session's own surface generation (agent.ts L128), so the next header is reason: "resume" and the old baseline stays. A new baseline only starts on a series header (tool-history.ts L36), for example after compaction replaces history.

So to fix that session without starting a new one:

1. Run /compact in it. The next header is reason: "series", and every current tool is declared normally from then on.
2. Or switch that session to DeepSeek-V4-Pro. It declares no toolUpdate, so each request sends all current tools as plain declarations and drops the update messages (content.ts L430-L437). This only lasts while the session stays on Pro.

I reproduced this on the published 0.2.0-rc.2 dsh web, with DEEPSEEK_BASE_URL pointed at a local mock that records request bodies. I added the tool mid-session by appending a plugin row to the profile cordis.patch.yml (HMR reload) instead of dsh plugin add. Results:

• Old session after the add: probe_alpha went out with defer_loading: true, plus a system message holding its tool_addition.
• Fresh session: the same 27 tools, none deferred.
• After a host restart: still deferred.
• After /compact: the header was reason: "series" and nothing was deferred.
• After switching to deepseek-v4-pro: nothing deferred.

The mock can't show how the real endpoint handles deferred tools.

The projection code is unchanged in 0.2.1-rc.3 and on master (22ddee3). On 0.2.1-rc.2 the same path causes the permanent 400s in #10553 and #10539 (tool_addition blocks can only be in system messages; there /compact fails too) and in #10163 and #8683 (all tools deferred). Since external PRs aren't accepted, upvoting those, or asking here for the "tools added mid-session stay deferred until the next compaction" behaviour to be documented, is the way to push it.

[dgesteves]

@cinast this is unchanged in 0.2.1-rc.4 and 0.2.2-alpha.2: deepseek-flash still declares toolUpdate: 'addition-only', and tools added mid-session are still sent deferred, so /compact or switching that session to V4-Pro is still the workaround. Did one of those fix the session for you? If so, marking the answer would help others who hit the same thing.

[cinast]

Hi, but 5 day lates,
I got distanced with my pc during warkdays, bit sorry.
But there's more progres.

Your explanation matches what I saw — and we now have the exact event that started it.

In the affected session, the first header listing the new tools is seq 4205 with reason: "resume", immediately followed by seq 4206 developer/message carrying tool-addition blocks for all of them (8 conversation_* + 13 godot_*). So they went out deferred, exactly as you describe — and nothing had a series header afterwards, which is why restarts and re-mounts never helped.

One accidental data point for the "fallback" path you mention: today a profile change produced a registry event with 10 tool-removal blocks plus 4 tool-addition blocks. Per snapshot() that leaves active.length !== available.size, so the projection should now declare the whole current header normally. That suggests a removal heals the deferred state as a side effect — accidental, but it may be worth documenting as one of the escape hatches (or at least as a behaviour to be aware of when toggling plugins mid-session).

Two things I'd still like confirmed:

1. Does the fallback path drop the tool_addition system messages entirely, or keep them alongside plain declarations? (Keeping them on a non-deferred tool would be harmless but noisy.)
2. On 0.2.1-rc.2 the same path 400s (Mid-conversation tool change places `tool_addition` blocks in a non-system message -> permanent 400 INVALID_REQUEST #10553/[Bug] DeepSeek adapter emits inline `role: "system"` `tool_addition` blocks → HTTP 400 that permanently breaks the session #10539). Is the intended long-term behaviour "deferred until next compaction" (documented), or is the projection supposed to re-baseline when the tool set changes size?

Attachment:

[seq 4205] 2026-10-24T12:27:05.000Z  request/header  reason=resume  tools=98
  ... conversation_link, conversation_list, conversation_rule, conversation_send,
      conversation_spawn, conversation_status, conversation_unlink, ...   (present in header)

[seq 4206] 2026-10-24T12:27:05.006Z  developer/message  headerSeq=4205
  tool-addition × 24:
    conversation_link, conversation_list, conversation_rule, conversation_send,
    conversation_spawn, conversation_status, conversation_unlink,
    godot_command, godot_create_project, godot_create_script, godot_export_project,
    godot_get_debug_output, godot_headless_op, godot_manage_autoloads,
    godot_manage_export_presets, godot_manage_input_map, godot_ping,
    godot_run_headless, godot_run_project, godot_screenshot, godot_set_engine_path,
    godot_set_project_setting, godot_stop_project, godot_validate_script

  note: no request/header with reason="series" occurs between seq 4206 and seq 9434
        → the baseline was never rebuilt, so those 24 stayed deferred for 6 days.

[seq 9435] 2026-10-30T10:39:08.052Z  developer/message  headerSeq=9434  (tools=107)
  tool-removal × 10:
    assistant_capabilities, glob, grep, pwsh, read,
    shoucang_associate, shoucang_recall, shoucang_suite,
    shoucang_targets_probe, shoucang_verify
  tool-addition × 4:
    ops_glob, ops_grep, ops_inspect_local_file, ops_result

[dgesteves]

@cinast thanks for digging out seq 4205/4206, that confirms it.

I don't think the removal itself heals anything. The loop writes that developer message right after the header, from the same name diff (agent.ts L692-L705), and the fold applies it to available (tool-history.ts L53-L56). So after seq 9435, available matches the header again and snapshot() keeps returning the deferred history. That fallback is only there for sessions written before update messages existed (the comment at L69). What does rebuild the baseline is a header with reason: "series" or startsSeries: true (set when the session surface was replaced, e.g. by /compact), or a tool that kept its name but changed its definition (L32-L41). If the profile change did fix the session, header 9434 should show one of those.

1. The fallback drops them entirely. It returns updates: [], so projectToolUpdates skips every developer message (content.ts L460) and sends the current header as plain declarations. On the normal path, an addition for a tool that is already a plain declaration is filtered out too (L466), so the noisy duplicate never goes out.

2. "Deferred until the next series" is the intended design. The dynamic tool updates note says only explicit series starts and changed definitions rebuild declarations, and deferring exists to keep the cached prompt prefix. A change in the number of tools isn't meant to re-baseline. That note is internal, though, not user docs. Mid-conversation tool change places `tool_addition` blocks in a non-system message -> permanent 400 INVALID_REQUEST #10553 and [Bug] DeepSeek adapter emits inline `role: "system"` `tool_addition` blocks → HTTP 400 that permanently breaks the session #10539 have no maintainer reply yet, and I don't see a fix for the 400 in the rc.3 to rc.5 or 0.2.2-alpha.2 notes, so the long-term answer is the maintainers' call. Your seq 4205/4206 excerpt would be useful in one of those threads.

Checked against main at ce7073d.