Editing a profile patch layer while DSH is running strips the agent's tools from live sessions

[l33tdawg]

Editing a profile patch layer while DSH is running strips the agent's tools from live sessions

Severity: high. The session stays alive but can no longer read, write, or run anything.

What happens

Editing the profile's patch layer, cordis.patch.yml, while dsh is running removes most of the session's tools. The session keeps running, and every call to a removed tool returns Error: unknown tool "<name>". Nothing in the transcript says why.

Restarting restores everything, which is what makes it expensive to diagnose: it looks like the profile is broken, so the natural move is to revert the config change rather than restart.

A later install that edited only package.json did not reproduce it, so the trigger looks specific to
the patch list rather than to the profile directory in general. The evidence for that is under
the trigger below.

Exactly what is lost

From the session log, comparing the request/header before and after. 65 tools become 41.

Lost (25):

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         send_message  skill          subagent_fork  todo_write
update_goal        web_fetch     web_search     workflow       write

Survived (41): 35 mcp__sage__* tools, plus apply_patch, read_mcp_resource, list_mcp_resources, list_mcp_resource_templates, load_workspace_dependencies, subagent.

The split is not random. The survivors are the tools contributed by profile rows mounted outside the agent preset. Everything the preset contributes goes, including the tools the agent cannot work without.

The practical effect: the session can still talk to its MCP servers, but it cannot read a file, write one, or run bash. It is not a degraded session, it is a useless one.

subagent surviving while subagent_fork, list_agents, send_message and interrupt_agent all vanish is unexplained. All five come from tool-subagent rows in the same preset (packages/bundle/base/cordis.patch.yml:364-376), so a plain scope teardown does not account for it.

Reproduction

1. Start dsh, confirm bash and read work.
2. In another terminal, write to ~/.dsh/profiles/<name>/cordis.patch.yml. Changing a value in an
   existing row is enough; the first and second events did that and appended a row respectively.
3. Call bash in the running session.

Expected: the edit has no effect until restart, or the reload completes and tools remain.

Actual: 25 tools gone for the rest of the session.

Editing only package.json did not reproduce it in a later attempt, so treat the patch file as the
trigger and the manifest as unconfirmed.

A control I ran

Both times this happened, I had also just used a sandbox escalation, so escalation was a candidate cause. It is not: I ran four escalated commands later in a healthy session (adding a git remote, committing, pushing, removing scratch files) and the tool count stayed at 66 throughout. The profile edit is the trigger.

Evidence

Reproduced twice on the same profile, with the tool counts above as the record.

The first time, I had just installed three plugins and rewritten package.json plus appended a row to cordis.patch.yml. I assumed the install was at fault, had the user revert it, and restarted. The revert was unnecessary: later, with the plugins still installed and no revert, a restart came up with all 66 tools.

The second time, the only change was one value in cordis.patch.yml. Same result.

--dump-config composes correctly in both states, and booting a throwaway copy of the same profile activates every entry, so composition is fine and the damage happens only in the live reconcile.

The trigger is narrower than "any profile edit"

A third install refined this. Editing only package.json to add a bundle left the session intact:
the tool count went 66 to 67, the new tool mounted, and nothing was lost. Both earlier events edited
cordis.patch.yml.

Event	Profile file edited	Tool count
First	package.json and cordis.patch.yml	65 to 41
Second	cordis.patch.yml only	66 to 41 to 40
Third	package.json only	66 to 67, intact

So the earlier framing, "editing any config file in the profile directory", is too broad. The
correlation is with the patch layer. Two observations against one is not proof, and I have not run
the edit that would confirm it because doing so costs a session, but it points at the patch list
being what changes rather than the manifest.

Mechanism

Traced. packages/boot/hmr/src/index.ts watches the profile's patch files and, on a change, calls
reconcileProfilePatches:

const patches = readProfilePatches('dsh', profile)
const warnings = await reconcileProfilePatches(this.ownerContext.root, patches, 'dsh')

reconcileProfilePatches resolves the root Include entry, the one that mounts the whole
application (bootstrapIncludes.set(ctx, entry) where entry = loader.resolve(includeId)), and
re-applies it:

await entry.update({ config: { ...includeConfig, patches: prepared } })

Updating the root entry's config rebuilds the plugin tree beneath it. Plugins mounted at the root
re-run apply(), which is why tools contributed by top-level rows came back. The live agent's own
scope is not rebuilt, because the agent already exists and nothing recreates it, so every
registration its preset made into that scope is gone.

That accounts for the observed split: root-contributed tools survived, preset-contributed tools did
not. It does not explain the one anomaly above, subagent surviving while subagent_fork,
list_agents, send_message and interrupt_agent vanished, which suggests tool-subagent is also
mounted at root scope somewhere that I did not chase down.

It also fits the third event: a manifest-only change that leaves the patch list identical produces
an entry.update whose config is unchanged, so the tree is not rebuilt and nothing is stranded.
That is a guess at the mechanism behind the correlation, not a measurement.

It accounts for the silence, which is the expensive part. reconcileProfilePatches does raise on
newly introduced activation failures:

if (introduced.length > 0) throw new Error(activationDiagnostic(binName, introduced).trimEnd())

but nothing failed to activate. Every plugin is healthy. The tree they were mounted into for that
agent is simply not the tree the agent is still holding.

Workaround

Restart after editing the profile. Do not edit profile files from inside a running session.

Environment

• DSH dsh-v0.2.0-rc.2, commit 639ed0153
• macOS, desktop profile, @deepseek-ai/dsh-base and @deepseek-ai/dsh-web-app plus three local plugins
• Counts read from request/header records in session.v4.jsonl.zstd

[l33tdawg]

Follow-up after living with this for a day. The lost tools are the visible problem; the silence is the expensive one.

Every call to a removed tool returns unknown tool "<name>" and nothing else. No indication that a reload happened, that the tool existed moments earlier, or that a restart would restore it. From inside the session there is no way to tell "this harness never had a bash tool" apart from "this session had one ninety seconds ago and something took it away".

That cost three restarts today. The natural reading of unknown tool "bash" is that the harness is misconfigured, so the instinct is to revert configuration and restart. That is the wrong direction, and reverting a working config makes the next restart worse rather than better.

Two suggestions, both small:

1. When a tool name does not resolve, say whether it was registered earlier in this session. The session log already has that, so the check is cheap and the message is the difference between reverting the wrong thing and restarting.
2. If a reconcile removes tools from a live agent, record that in the session. Silently applying a partial teardown is what makes the symptom unattributable.

Counts from the two events, for whatever they are worth: 65 tools to 41, then 66 to 41 to 40. The surviving set was the 35 mcp__sage__* tools plus six contributed by top-level rows, so the session retained its MCP servers and lost read, write, bash, edit, grep and glob.

[l33tdawg]

A fix for the reporting half of this, on a branch since the repository takes no pull requests:

fix/profile-reload-strands-agents on l33tdawg/deepseek-harness.

It does not stop the rebuild. It makes the damage visible, because silence is what made this cost three restarts: from inside the session, unknown tool "bash" reads as a misconfigured harness, so the instinct is to revert configuration, which is the wrong direction.

reconcileProfilePatches already returns diagnostics that HMR logs as warnings, so the detection reports on that channel rather than throwing. A reload that strands a session is still a reload that applied, and refusing it would remove the one thing profile reload is for.

Each live agent's visible tools are snapshotted before the patch generation is applied and again after it settles:

const toolsBefore = visibleToolsByAgent(ctx)
await entry.update({ config: { ...includeConfig, patches: prepared } })
// ... settle ...
return [
  ...failures.map(inactiveDiagnostic),
  ...strandedToolDiagnostics(toolsBefore, visibleToolsByAgent(ctx), binName),
]

A stranded agent produces:

dsh: session <id> lost 2 tool(s) across the profile reload: write, bash.
The change applied, but this session holds plugin scopes from the previous tree,
so restart to restore them.

An agent that disappears across the reload is not reported, since it ended rather than lost anything, and a composition mounting no agent or tool registry skips the comparison.

Three tests: a loss, no loss, and no registry. The loss case fails without the change and passes with it.

What it does not do is the harder half. A patch that changes one value in a profile layer still rebuilds the application tree, and the live agents are still left holding scopes from the previous one. Reporting turns an unattributable failure into an attributable one; it does not make the reload safe. That part needs either a narrower rebuild than the root entry or a rebuild of the agents alongside it, and I did not attempt it.

[l33tdawg]

This thread's title is the question, so here is the boundary, measured rather than inferred - and it also explains a result that looked like it contradicted this report.

What a profile edit reaches

dsh-hmr registers three exact-path watches (@deepseek-ai/dsh-hmr/lib/index.js:353-376 in 0.2.0-rc.2):

const manifestPath = join(profile.dir, "package.json")
const patchFiles = [profile.patchPath, join(profile.home, PROFILE_PATCH_FILENAME)]
const refresh = async (manifestOnly) => {
  const bundles = JSON.stringify(readProfileManifest("dsh", profile.dir).dsh?.profile?.bundles ?? [])
  if (manifestOnly && bundles === lastBundles) return
  const inputs = JSON.stringify([bundles, ...patchFiles.map((filename) => readFileSync(filename, "utf8"))])
  if (inputs === lastInputs) return
  const patches = readProfilePatches("dsh", profile)
  const warnings = await reconcileProfilePatches(this.ownerContext.root, patches, "dsh")
  ...
}
for (const filename of patchFiles) await this.watchConfig(filename, () => refresh(false))
await this.watchConfig(manifestPath, () => refresh(true))

A patch-file write therefore always recomposes; a package.json write matters only through the ordered dsh.profile.bundles list; a write whose composed inputs are unchanged is skipped. reconcileProfilePatches then re-applies the root Include entry - entry.update({ config: { ...includeConfig, patches: prepared } }), @deepseek-ai/dsh-app-boot/lib/index.js:3481-3488 - and awaits the fibers that existed before it.

Nothing in that path re-mounts an agent. An agent's scope, the preset it was mounted from and every registration that preset made into it are resolved at mount, which for a resumed session means the next launch. So the answer depends on which layer the edited row belongs to, and the log agrees:

Profile write	In running sessions
2026-10-02 06:19:30.955Z, patch + manifest (three bundles added to the ordered list, plus a new profile-layer override of agent-preset-registry)	4 sessions lost the same 25 tools, the first at +3.0 s with reason=change; unknown tool errors follow immediately
2026-10-02 08:22:27.974Z, patch + manifest (one bundle added)	4 sessions gained check_claims, the first at +2.5 s, nothing lost
2026-10-03 01:15:24.145Z, patch only (a preset-cordis override repairing its customSkillDirs root)	no tool-surface change in any session, and no cordis skill catalog for the next 3 h; the first cordis catalog in the corpus arrives 10 s after the app relaunch

Times are UTC. After the first instant in each row, the others are when each session next took a turn rather than when the change landed.

The two comments above are the reporting half and the detection half of this. What the boundary adds
is when to expect the damage: rows 1 and 2 both create or remove a profile-layer override of a
host-plane row, and rows 3 and 4 - which only changed a value inside an existing override, or
restated a preset's declaration - stranded nothing at all. A detection patch that labels a stranded
reload is more useful with that shape attached, because the transcript cannot tell the four writes
apart today.

Two corrections to this report

The third install was not manifest-only. It names "editing only package.json to add a bundle" as the case that mounted a tool cleanly. That install wrote package.json at 08:22:27.974Z and cordis.patch.yml at 08:22:27.977Z, 3 ms apart, and the manifest path alone is gated on the bundle list. A genuinely manifest-only install followed 30 minutes later in the same profile (dsh-edit-feedback, added to the ordered list); it mounted no tool, because that bundle contributes none. So the corpus has no case of a tool mounting from a manifest edit at all, and the correlation with the patch layer survives - but that row does not demonstrate what it says it does.

The loss is not a property of the patch layer. The same file, written twice in two hours, took 25 tools away and then added one cleanly. What separates the two writes is the shape of the patch entry, and this is where measurement stops: the destructive write introduced a new profile-layer override of an existing host-plane row (agent-preset-registry), which the Loader has to dispose and re-create, while the clean one only changed a value in an override row the profile layer already owned ("Loader commits volatile-only changes in place", dsh-hmr/README.md:57). If that distinction is the answer, the defect is sharper than the title - a row-level dispose and re-create strands an already-mounted agent's preset scope - and nothing in the transcript says so.

One more correction, because it is the first thing we tried to check against the source: the survivors are not "the tools contributed by profile rows mounted outside the agent preset". @deepseek-ai/dsh-base/cordis.patch.yml inserts 94 rows at top level, tool-bash, tool-fs, tool-todo, tool-web and tool-skill among them, and the preset selects those ids for its agent. What dies is the preset's selection. mcp-resources and subagent survive it and we could not account for those two from the layers alone.

What we can hand over

The cheap experiment for the shape question is one profile write of each shape against one live session, reading the next request/header's reason (change means the surface moved). We can run it if it is wanted. We have not, because the destructive shape costs whatever that session was doing.

Independent of the above, and worth a look on your side: a bundle installed into a profile but never added to dsh.profile.bundles is invisible to a running app, and the reload is skipped silently - there is no diagnostic for "your manifest changed and nothing happened".