[Bug] Live sessions become permanently tool-dead and lose the permission picker: cannot get required service "sessionProjections" in inactive context, turn/end still reports completed

[fxy21638]

摘要（中文）

DSH desktop 0.2.0-rc.2 / Windows 11。核心问题不在某个插件，而在 dsh-hmr 的默认行为：dsh-base 以 root: [] 启用 HMR，而 README 明确写着 []「仍保留显式配置监听」——也就是默认就会监听用户 patch 层（cordis.patch.yml）。任何对它的写入都会触发插件树重建，正在运行的 session scope 随之失效，于是每一次工具调用都在派发前死掉：

permission: permissions session projection is not registered
cannot get required service "sessionProjections" in inactive context

同时界面上的权限选择器消失。与 #8857 的区别：这里 session 没有被 dispose —— turn/end 是 completed，会话变成「活着但永远调不动工具」的僵尸。

本次触发者是一个第三方插件（@linxin666/dsh-pet，经 @linxin666/dsh-web-all 传递引入）：它把桌宠坐标持久化进 patch 层，而这只宠物在持续保存位置。同一份 diff 里还有两条通过界面新增的 MCP insert。

⚠️ 但随后的对照实验没有复现：在一次会话正常运行时故意两次写入该文件，会话没有变哑。所以「写入 patch 层 → 必然炸」不成立，见下文「负结果」。本报告真正立得住的是症状链与会话不恢复这一点，触发条件仍是开放的。

---

TL;DR

Profile: desktop. Two live sessions in it lost every tool call at the same moment. The first failure is

permission: permissions session projection is not registered

and every subsequent dispatch fails with

cannot get required service "sessionProjections" in inactive context

The permission picker also disappeared from the GUI. Unlike #8857, the sessions were not disposed: turn/end reports {"kind":"completed"}, so they stay alive and permanently unable to dispatch a tool.

The suspected trigger is a write to the user patch layer cordis.patch.yml, which dsh-base makes dsh-hmr watch by default. The writer in this instance appears to have been a third-party pet plugin persisting its dragged position (plus two MCP insert blocks added through the UI).

However, a deliberate probe of that write did not reproduce the wedge (see Negative result below). The write alone is therefore not sufficient; the additional condition is unknown. What this report establishes firmly is the symptom chain and the fact that the session never recovers.

Environment

• @deepseek-ai/dsh-desktop 0.2.0-rc.2, Electron 44.0.0, Node 24.18.1, Windows 11 x64
• profile desktop, bundles: @deepseek-ai/dsh-base, @deepseek-ai/dsh-web-app, @deepseek-ai/dsh-experimental-agent-team-profile, @deepseek-ai/dsh-experimental-auto-review, @linxin666/dsh-web-all, @noop-stupid/dsh-plugin-console, dsh-better-sidebar, dsh-workbuddy-connect, dsh-our-free-model, dsh-ops

The core behaviour

@deepseek-ai/dsh-base/cordis.patch.yml enables HMR for every profile that has a profileContext:

# dsh-base/cordis.patch.yml:27
# Profile configuration reloads by default; module roots are opt-in.
- id: hmr
  name: '@deepseek-ai/dsh-hmr'
  disabled: !!js "!ctx.get('profileContext')"
  config:
    root: []

@deepseek-ai/dsh-hmr/README.md states the consequence explicitly:

root: Module watch roots; [] retains only explicit configuration watches.

and

Exact configuration watches also observe additions, removals and initially missing parent directories. They default to awaitWriteFinish: true: edits wait for Chokidar's 2-second write-stability window.

The watches are registered in dsh-hmr/lib/index.js:

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

with PROFILE_PATCH_FILENAME = "cordis.patch.yml" and patchPath = join(dir, PROFILE_PATCH_FILENAME) (dsh-app-boot/lib/index.js:487, 588, 946, 1141).

So the default profile watches its own user patch layer, and reconcileProfilePatches rebuilds the tree, disposing live session/agent scopes:

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

Per the sessionProjections API documentation (dsh-tool-cordis/lib/types/api-catalog.js:2087):

Registration is an effect (disposer rides the calling fiber): an unloaded domain plugin's key disappears from snapshots and clients read it as capability absence.

So the rebuild removes the permissions key — dsh-permission-presets/lib/index.js:279 then throws permission: permissions session projection is not registered, which is also why the client stops rendering the permission picker — and service lookups then resolve against an inactive context, so ctx.get("sessionProjections") fails for every dispatch (dsh-session-projection/lib/index.js:52 installs the registry as super(ctx, "sessionProjections")). That is why every tool family dies at once, including tools that touch no filesystem and no process.

Note: the pet is not part of DSH. It is the third-party plugin @linxin666/dsh-pet 0.4.4, pulled in transitively by the third-party bundle @linxin666/dsh-web-all. It is not a direct dependency of the profile. I am reporting it only because it is the concrete writer; the defect being reported is the default config-watch + rebuild behaviour and the fact that a wedged session never recovers.

Timeline (reconstructed from the session logs)

Two sessions in the same profile, both working normally until the same moment:

session-79105416   (started 00:19:51)
  00:23:11  permission/preset="danger-full-access"  approval/policy="never"
  00:24:14  turn/start
  ...approx. 270 events of normal work (turn 3, steps 1..31)...
  00:33:56  first tool/result carrying "inactive context"   (turn 3, step 32)
  00:34:00, 00:34:02, 00:34:05, 00:34:07 ... every later call fails
  00:34:28  turn/end {"turn":3,"reason":{"kind":"completed"}}      <-- not disposed
  00:34:38  turn/start (turn 4); every call still fails

session-a6760a94   (started 00:30:13)
  00:30:35  permission/preset="auto"  sandbox/mode="danger-full-access"
  00:33:52  first tool/result carrying "inactive context"
  00:34:16  turn/end {"turn":1,"reason":{"kind":"completed"}}

Both sessions began failing 4 seconds apart while doing unrelated work, and neither recorded turn/end {"kind":"aborted","reason":{"kind":"disposed"}}.

Evidence: the watched patch file was rewritten inside the incident window

C:\<dsh home>\profiles\desktop\cordis.patch.yml was rewritten at 00:35:45, inside the incident window. The complete delta against the previous Plugin-Manager backup (cordis.patch.yml.bak-20261015-232654, taken 23:26:54) is:

@@ -274,4 +274,34 @@
     size: 160
-    right: 49
-    bottom: 437
+    right: 56
+    bottom: 464
     petId: whale-girl-refined
+- insert:
+    - id: mcp-windows-mcp
+      name: '@deepseek-ai/dsh-mcp-client'
+      config:
+        serverName: windows-mcp
+        ...
+- insert:
+    - id: mcp-tomc-memory
+      name: '@deepseek-ai/dsh-mcp-client'
+      config:
+        serverName: tomc-memory
+        ...

So the only content change is a plugin's persisted runtime UI state (the pet's dragged position) plus two MCP server inserts — i.e. ordinary use, not a deliberate configuration edit. The pet also rewrites its own pet.json continuously (observed at 00:23:18, 00:46:27, 00:48:31).

pet.json in the same window shows the pet still moving (right 101 -> 84, bottom 467 -> 491), i.e. the plugin was actively persisting state throughout the incident.

There is no host-side log for the incident: logs\ gained no new file. The failure is silent.

Negative result — the patch-file write alone does not reproduce it

While a session was running normally, cordis.patch.yml was written nine times on purpose, including a burst at roughly 6-second intervals. The session kept dispatching tools normally throughout, including ~20 s after the last write.

A 2-second mtime watchdog over the watched files confirmed every write landed:

00:49:36  CHANGED  cordis.patch.yml  8902 bytes
00:52:01  CHANGED  cordis.patch.yml  8933
00:52:13  CHANGED  cordis.patch.yml  8951
00:52:39  CHANGED  cordis.patch.yml  8972
00:52:45  CHANGED  cordis.patch.yml  8993
00:52:51  CHANGED  cordis.patch.yml  9014
00:52:57  CHANGED  cordis.patch.yml  9035
00:53:03  CHANGED  cordis.patch.yml  9056
00:53:27  CHANGED  cordis.patch.yml  9240

Two of those writes changed the mounted plugin set (they set - id: hmr / disabled: true), i.e. they were not mere config-value edits.

The reconcile really did run: cordis.yml — the composed tree — was also rewritten at 00:49:36 and 00:52:05, which only happens when the profile is recomposed. Sessions survived anyway.

So a write to the HMR-watched patch layer is not sufficient to wedge a session, and the reconcile/rebuild it triggers is normally survivable. The wedge needs an additional condition that I have not identified. This also means the mechanism I described above is a plausible route to the symptom rather than a demonstrated cause of this incident.

Candidate conditions I could not distinguish with the data available:

• whether the reconcile lands while a tool call is in flight;
• whether the profile is shared by several live sessions/agent scopes at that moment (both wedged sessions shared one profile, and a session in a different workspace had stopped ~1m45s earlier);
• whether some other session-lifecycle event (session close/open, end-seed, a projection-cache checkpoint) is the real trigger and the patch write is unrelated.

A host-side log line per reconcile (what changed, what was disposed, which session scopes were affected) would settle this in a single occurrence; the app currently writes no host log for this event at all.

What is proven and what is not

Proven (from logs and files on disk):

• the error sequence and that it affected every tool family;
• two sessions in one profile beginning to fail 4 s apart;
• turn/end completing normally rather than disposed;
• the permission picker disappearing;
• cordis.patch.yml being in HMR's watch list by default via dsh-base, and being rewritten inside the window;
• the delta of that file being a third-party plugin's persisted UI state plus MCP inserts.

Not proven: which exact write fired the rebuild. File mtime only retains the last write. I have installed a 2-second mtime watchdog over cordis.patch.yml, cordis.yml, package.json and pet.json to capture the next occurrence and will follow up with timestamps.

Relation to existing reports

• [BUG] Changing cordis.patch.yml while sessions are running kills every running session mid-turn #8857 — same rebuild mechanism, but there the writer is a deliberate installer write to cordis.patch.yml and the sessions die (turn/end aborted/disposed). Here the writer is ordinary plugin state persisted through the same layer and the sessions survive as zombies, which is harder to notice and cannot be recovered by reopening the session.
• file-upload: Agent resolver is already registered - any cordis.patch.yml reload permanently kills sessionController, and every later reload fails the same way #8968 — cordis.patch.yml reload permanently kills sessionController; same family.
• tool-cordis registers Host inspect providers globally → any second mount of a preset containing it fails (New Session appears to do nothing) #7147 — a second mount of a preset fails; same mount/refcount area.
• Duplicate in-box `@deepseek-ai/*` package in a profile silently breaks every tool call #8287 — a duplicate in-box package breaks every tool call; similar blast radius, different cause.

Suggested fix direction (core-side)

1. Do not watch and reconcile the user patch layer while sessions are running; defer the reconcile until idle, or require an explicit reload (the expectation stated in [BUG] Changing cordis.patch.yml while sessions are running kills every running session mid-turn #8857).
2. Do not rebuild the root Include for changes that only touch a plugin's runtime config row; a config override does not need a tree rebuild that disposes session scopes.
3. On rebuild, live sessions should be migrated to the new scope or explicitly disposed with a user-visible error — not left with permanently failing service lookups.
4. A missing projection key should not be able to wedge tool dispatch indefinitely; dispatch should fail loudly once rather than failing every call forever.
5. Consider a documented, non-watched channel for plugin runtime state, so that plugin authors have somewhere safe to persist UI state (the pitfall here is easy to fall into from a plugin).

Interim workaround

• Disable the HMR row in the user patch layer (this is the documented way; dsh-acp-app/cordis.patch.yml:23 does exactly this):

  - id: hmr
    disabled: true

  Per the README, this applies on the next start, after which profile-config writes no longer trigger a rebuild.

• Remove or hide the pet plugin (stops the frequent writes).

• Do not add/edit MCP servers, plugins, or plugin settings while sessions are running.

[longxing-alt]

Second independent report — same symptom chain, plus a per-session pattern and a self-heal step

TL;DR

Same failure on 0.2.0-rc.2 desktop / Windows 11 x64, with one more data point that may narrow the trigger: the wedge is per-session, not per-host, and it can be cleared from the UI without restarting.

Three things I could not find in the original report:

1. A healthy control in the same process. Two sessions 2–15 minutes apart from the wedged ones dispatched 176 and 210 tool calls with zero inactive context failures, in the same host process, under the same profile.
2. Two distinct shapes. Dead-at-first-call (7/7 failures from step 1) and dead-mid-turn (73 good calls, then 8/8 failures starting a later turn). The original report describes only the second.
3. A self-heal. One session failed 5 consecutive dispatches, then two permission/preset events were appended, and the next 10 of 10 calls succeeded — no restart.

Environment

• @deepseek-ai/dsh-desktop 0.2.0-rc.2, Windows 11 x64, profile desktop
• heavily extended profile: dsh-ops, three local plugins mounted through junctions (dsh-usage-board, dsh-project-progress, dsh-thinking-effort), three dsh-mcp-client inserts
• HMR: dsh-base default (root: [], profile config watched) plus an explicit module root pointing at a local plugin's source tree

Evidence

Read from ~/.dsh/sessions/*/session.v4.jsonl.zstd (multi-frame zstd — one frame per append, so a single zstdDecompressSync call returns only the first frame; the frames have to be walked).

session (short)	session start	tool results	inactive context failures
16c6bfa6	10-16 13:59Z	81	8 — first 73 ok, then 8/8 fail from turn 3
5fda2c61	10-17 01:44Z	5	4
8642e09c	10-17 01:47Z	15	5 — then healed
f175e5d2	10-17 01:49Z	210	0
593661f8	10-17 01:59Z	176	0
1f9c9e64	10-17 05:08Z	7	7 / 7, from the first call

The 01:44 / 01:47 sessions are wedged; the 01:49 / 01:59 sessions are clean. Same machine, same profile, minutes apart. A host-wide "the plugin tree was rebuilt once" story does not fit — the scope loss is per session.

The self-heal

8642e09c, in order:

seq 14  tool/call run_code      -> FAIL cannot get required service "sessionProjections" in inactive context
seq 21  tool/call run_code      -> FAIL
seq 30  tool/call run_code      -> FAIL
seq 37  tool/call run_code      -> FAIL
seq 60  tool/call run_code      -> FAIL
seq 70  permission/preset       {"preset":"workspace-write"}
seq 74  permission/preset       {"preset":"danger-full-access"}
seq 89  tool/call run_code      -> ok
seq 96  tool/call run_code      -> ok
... through seq 159, all ok

Switching the permission preset once re-established something and the session recovered. That points at a reconstructible per-session binding rather than the plugin tree — which would also explain why restarting the host "fixes" it and why a single write is so hard to turn into a reliable reproduction.

Also worth noting: a bare run_code program that touches nothing but Node still executes while every nested binding fails. The program runtime is fine; it is the host-side service resolution per dispatch that is dead.

Code pointers (0.2.0-rc.2)

These look like the reason the permission picker disappears in particular, rather than some other UI:

1. @deepseek-ai/dsh-permission-presets/lib/index.js — the constructor's first substantive statement is ctx.sessionProjections.register({ key: 'permissions', ..., wire: { view: (state) => ({ currentValue: this.derive(state) }) } }). If sessionProjections is not resolvable at mount time, the plugin throws and the permissionPresets service never appears — the picker then has nothing to render.

2. permissionState(session) throws permission: permissions session projection is not registered when the key is absent, which matches the first error line in the original report.

3. pinInitialPermission(session) is bound to ctx.on('session/created') and run over ctx.sessions.list() in the constructor. It throws both when the projection is missing and when the stored preset is auto while autoAdmit === undefined:

if (preset === "auto") {
  if (this.autoAdmit === void 0)
    throw new Error('permission: cannot restore preset "auto" without its active integration')

A throw inside the session/created handler aborts that session's initialization — a plausible explanation for the dead-at-first-call shape, since the damage would be done at creation, before any tool runs.

4. @deepseek-ai/dsh-experimental-auto-review is the only registerAuto() caller, and auto appears in presets.names only while that integration is live. In my composed profile it is mounted as the last top-level row, after permission — so there is an ordering window in which permission exists and auto does not. One of the wedged sessions opens with:

command/run        name=permission  args=" auto"
permission/preset  {"preset":"auto"}

What I could not establish

• Which fiber is actually inactive. The message is a flattened symptom; discussion dsh-settings: one plugin exporting `Config = null` crashes `describe()` for the whole runtime, and the failure surface is a misleading "inactive context" error #7900 makes the same point about settings ("the failure surface is a misleading inactive context error"). Without host stderr captured at the moment of failure this stays open.
• That writing the patch layer is sufficient. My data agrees with the negative result in the original report: two wedged sessions and two clean ones interleaved within minutes is not consistent with "any single write wedges the profile". Something additional is required.

Suggested direction

• Do not let a projection-registration failure remove permissionPresets for the whole process.
• Do not throw from a session/created handler; degrade that session's permission state and surface it, rather than leaving the session alive but unable to dispatch.
• Tool dispatch should not be hard-dependent on a UI-facing projection service.
• Make permissions session projection is not registered distinguishable from inactive context — right now both collapse into the same unhelpful message.
• Expose loader/plugin state at runtime so a wedged session can be diagnosed without restarting, since restarting destroys the evidence.