[BUG] Changing cordis.patch.yml while sessions are running kills every running session mid-turn

[terri-yaki]

Summary

If the profile patch file changes while sessions are running, all of them are disposed at the same moment, in the middle of a turn. In the UI the sessions just disappear, which looks like they were deleted. They aren't — the logs are still on disk — but only the session you reopen comes back.

I hit this on DSH desktop (0.2.0-rc.2), profile desktop, Windows 11.

What I did

I was working on a small plugin whose installer writes a managed block into the profile's cordis.patch.yml — the same file the Plugin Manager writes. I had two sessions open in one workspace, both mid-turn, and ran the installer.

What happened

About two seconds later both sessions ended at almost the same instant, 34 ms apart, while still working.

The first thing that broke was an in-flight tool call:

{"type":"tool/ptc-dispatch","seq":333,"data":{
  "name":"job_output",
  "arguments":{"job_id":"pwsh-124","wait":true,"timeout_ms":480000},
  "isError":true,
  "content":[{"type":"text","text":"Error: cannot get required service \"jobs\" in inactive context"}]}}

Then both sessions recorded the same turn end — first the unrelated one, then the session that ran the installer:

{"type":"turn/end","seq":336,"data":{"turn":1,          // session B (the unrelated one)
  "reason":{"kind":"aborted","reason":{"kind":"disposed"}}}}

{"type":"turn/end","seq":827,"data":{"turn":1,          // session A (ran the installer)
  "reason":{"kind":"aborted","reason":{"kind":"disposed"}}}}

One of them was the session that ran the installer; the other was an unrelated session in the same profile, waiting on a background job. The second session was not doing anything to its configuration.

The same thing happened again later, this time to the session that ran an uninstall of the same plugin. Its tool call came back with a job id that no longer existed, and then the turn aborted the same way:

{"type":"tool/call","seq":849,"data":{"name":"pwsh",
  "arguments":"{\"command\": \"node scripts/install.mjs --uninstall …\"}"}}

{"type":"tool/result","seq":850,"data":{
  "message":{"role":"tool","content":[{"type":"text","text":"Error: unknown job pwsh-141"}],
  "isError":true}}}

{"type":"turn/end","seq":852,"data":{"turn":2,
  "reason":{"kind":"aborted","reason":{"kind":"disposed"}}}}

Timeline (local time):

01:04:22  session A runs the installer        (writes cordis.patch.yml)
01:04:26  session A → turn/end aborted/disposed
01:04:26  session B → turn/end aborted/disposed      (34 ms later, unrelated session)
01:05:16  session A re-seeded after I reopened it; session B never was
01:10:38  session A runs the uninstaller
01:10:42  session A → turn/end aborted/disposed

What I expected

Reloading the plugin row that changed, or (if a reload has to interrupt sessions) waiting until they're idle and saying so. I did not expect a config write to end turns in other sessions.

Where it seems to come from

@deepseek-ai/dsh-hmr watches both patch layers and reconciles them on change:

// dsh-hmr/lib/index.js
const patchFiles = [profile.patchPath, join(profile.home, PROFILE_PATCH_FILENAME)];   // :354
…
const warnings = await reconcileProfilePatches(this.ownerContext.root, patches, "dsh");  // :370
for (const filename of patchFiles) await this.watchConfig(filename, () => refresh(false)); // :375

reconcileProfilePatches then updates the root Include with the full new patch list:

// dsh-app-boot/lib/index.js
const entry = bootstrapIncludes.get(ctx);            // the root Include entry     :3469
…
await entry.update({ config: { ...includeConfig, patches: prepared } });          // :3484
const results = await Promise.allSettled(previousFibers.map(({ fiber }) => fiber.await()));  // :3488
await ctx.loader.await();

Updating the root include rebuilds the tree, so live session and agent scopes get disposed. The agent loop cancels the running turn with cause disposed (dsh-agent-loop/lib/index.js:1688, :1906), which is what shows up as turn/end {"kind":"aborted","reason":{"kind":"disposed"}} (:737, :1012). The tool errors above are the same event seen from inside an in-flight call: the services it needed were already gone.

The ~2 second delay matches the chokidar awaitWriteFinish window that config watches use by default (dsh-hmr/lib/index.js:52).

The dsh-hmr README says this behaviour is intended ("Profile and home patch changes also trigger recomposition"), so I'm reporting the effect on running sessions rather than the reload itself.

Steps to reproduce

1. Open the app with a live profile (desktop).
2. Start two sessions in a workspace and get both mid-turn — e.g. one waiting on a background job, one streaming.
3. From another process, change the content of %USERPROFILE%\.dsh\profiles\desktop\cordis.patch.yml (adding or removing one plugin row is enough; Plugin Manager's enable/disable does the same thing).
4. Both sessions end within a few seconds.

Worth knowing before you try it: this kills the running sessions, so don't do it in a session you need.

Notes

• The sessions are not actually deleted. dsh-session-persistence-jsonl/README.md says nothing deletes session files, and both logs are intact (%USERPROFILE%\.dsh\sessions\<workspace>\<session-id>\session.v4.jsonl.zstd), with their entries still present in storages\workspace.json.
• The abort reason doesn't say why. {"kind":"disposed"} is indistinguishable from a user cancel in the transcript, and the tool errors read like broken infrastructure (cannot get required service "jobs" in inactive context) rather than "the host reloaded". That's the part that made this look like data loss to me.
• Only the session I reopened was re-seeded afterwards; the other stayed disposed until I opened it manually.
• I'd be happy to attach the decoded logs (854 and 339 events) if that's useful. They're multi-frame zstd, so they need splitting on the zstd magic before parsing.

Environment

DSH desktop 0.2.0-rc.2 (bundled @deepseek-ai/dsh 0.2.0-rc.2)
Windows 11 Pro 26300, bundled Node runtime v24.11.0
profile: desktop (live — HMR enabled)
patch layers: %USERPROFILE%\.dsh\profiles\desktop\cordis.patch.yml
              %USERPROFILE%\.dsh\cordis.patch.yml