[Bug]回合运行中改模型/思维强度/权限，会让会话所有工具调用失效（sessionProjections in inactive context）

[VillagerUncle02]

故障现象

会话跑到一半，工具突然全部调不动，之后每次调用都是：

cannot get required service "sessionProjections" in inactive context

（#9812 的报告里前面还会先出现 permission: permissions session projection is not registered；我这边只出现上面这条。）

几个特征：

• turn/end 仍然是 completed，会话看起来还活着，但 nested 工具调用全死；
• run_code 外层还能跑（里面纯 Node 的代码正常），只有 tools.* 内层绑定全部失败；
• 权限选择器从界面上消失；
• 重启 host 能恢复；有时切换一次权限预设也能把会话救回来。

环境

• Windows 11 x64
• DSH Desktop 0.2.1-rc.1 和 0.2.1-rc.2 都遇到；历史日志显示更早版本（0.2.0-rc.2 及更早）同样出现过
• profile：desktop
• bundles：dsh-base、dsh-web-app、agent-team-profile、auto-review、voice-input-bundle、dsh-whale-widget、anysearch、experimental-terminal-bundle、experimental-session-search、dsh-ops、@memtensor/memos-local-plugin、tool-worktree
• 没有安装写 cordis.patch.yml 的第三方插件（没有 pet 之类），可以排除 [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 #9812 里怀疑的「第三方插件写 patch 层」这条路径

触发经过

今天下午干活时，我先后两次调整「思维强度」：先 high → max，后来 max → high。两次之后工具都开始报 inactive context，整个会话卡死。

一开始以为是偶发，后来翻 session log 才确认两次都对应得上。下表中的时间都是 UTC，与 session log 里的时间戳保持一致：

时间（UTC）	操作	结果
09:37:18	强度改成 max	09:43:11 请求头切到 max，09:43:19 起连续 16 次 inactive context
12:22:35	强度改回 high	12:22:38 请求头切到 high，12:22:43 起 又出现同样错误

这个会话全程只有这两簇错误，两次都对应改设置。核对轮次归属后，失败时机也更清楚了：

• 第一次：第 23 轮在 09:37:15 结束，09:37:18 记录 model/selection，下一轮（第 24 轮）09:43:10 开始、09:43:11 的请求用上新配置，09:43:19 第一次工具调用就失败；
• 第二次：第 30 轮第 1 步运行中（12:22:35）改设置，当时正在跑的调用正常返回，12:22:38 第 2 步的请求用上新配置，12:22:43 开始报错。

也就是说，重建发生时正在执行的请求不受影响，失败的是它之后的下一次模型请求——这次请求可能属于同一轮的下一步，也可能属于下一轮。这和「上一轮结束/运行中发生重建，下一轮工具就挂了」是同一个现象，只是第二次恰好在同一轮内就进入了下一个请求。

排查过程

一开始怀疑的是第三方插件。dsh-ops 接管了 shell 和文件工具，pre-execute 也挂在工具链上，看起来最像嫌疑。但读它的代码后可以排除：它只发布 ops_bash 这类带 ops_ 前缀的工具，pre-execute 只对固定的禁用工具名返回 deny，跟 sessionProjections 没有关系。

接着怀疑版本。rc.2 刚更新不久，时间点很近，所以把 npm 上 rc.1 / rc.2 的 auto-review、dsh-tools、user-approval、permission-presets、agent-loop 和审批 UI 包都拉下来对比，lib 代码的 sha256 完全一致，bundle patch 也只是多了模型标签和搜索 API。版本回归这条也排除了。

再怀疑服务端：限流、并发、审批通道故障。翻了相关会话的事件，llm/retry、429、request/error 一个都没有；审批事件确实触发过并正常完成。所以也不是外部服务或审批链路。

三个方向都排除后，回到日志本身。把 ~/.dsh/sessions/*/session.v4.jsonl.zstd 按事件顺序展开，盯着工具失败前后的上下文看，发现每次失败前面都有同一个模式：model/selection → 下一次 request/header 用上新配置 → 几秒后开始报错。两次改设置，对应两簇错误，没有例外。

为了确认这不是巧合，又把全部历史会话扫了一遍：同样的错误最早出现在 2026-09-12，0.2.0-rc.2 时期也反复出现。同时发现触发面不止改模型——切权限预设、插件热重组合之后也会出现同样的错误。到这里才确定问题不在某个具体设置项，而是运行中重建 session/agent 绑定时，旧的 tool binding 没有失效。

复现步骤

1. 新建一个普通会话，发一条消息让 agent 调用工具（确保有 nested tool call）；
2. 在这一轮还在运行时，任选一种改动：
   • 把「思维强度」从 high 调到 max（或反向）；
   • 切换模型（同 provider 下换 model）；
   • 切换权限预设（例如 workspace-write → danger-full-access）；
   • 或者在插件页启用/禁用一个插件，触发重组合；
3. 观察 5–10 秒内是否开始出现 sessionProjections in inactive context，或者整轮 aborted before dispatch；
4. 日志里的顺序是固定的：配置事件 → request/header（或 sandbox）变化 → 首个错误 seq。

我这边 0.2.1-rc.1 和 0.2.1-rc.2 都能稳定踩到。

疑似同一问题的报告

• [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 #9812 — 症状链完全一致（sessionProjections in inactive context、turn/end completed、权限选择器消失），主报告
• [BUG] Changing cordis.patch.yml while sessions are running kills every running session mid-turn #8857 — 运行中写 cordis.patch.yml 杀会话，属于同一条「运行时重建」路径
• dsh-settings: one plugin exporting `Config = null` crashes `describe()` for the whole runtime, and the failure surface is a misleading "inactive context" error #7900 — 同样指出 inactive context 这个报错具有误导性，和这里看到的是同一个错误面
• 另外我这边历史会话里也有几次同样的错误（2026-09-12、2026-10-14、2026-10-16），当时没意识到是同一个 bug

证据

两次改强度对应两簇错误（会话 A）

以下片段直接来自 session log（~/.dsh/sessions/<session>/session.v4.jsonl.zstd），已做脱敏：
只保留事件类型、UTC 时间、模型配置、工具名和错误首行；用户消息、命令参数、工具输出和本机路径都没有包含。

# 第一次：high -> max（第 23 轮结束后改，第 24 轮第 1 步首次失败）
2026-10-17T09:37:18.135Z model/selection  {"model":"deepseek-flash","reasoningEffort":"max"}
2026-10-17T09:43:11.583Z request/header   {"model":"deepseek-flash","reasoningEffort":"max"}
2026-10-17T09:43:19.021Z tool/call name=run_code
2026-10-17T09:43:19.756Z ptc-dispatch name=grep isError=true
2026-10-17T09:43:19.807Z tool/result isError=true Error: code run failed (exception): ToolCallError: cannot get required service "sessionProjections" in inactive context
2026-10-17T09:43:22.238Z ptc-dispatch name=grep isError=true
2026-10-17T09:43:22.297Z tool/result isError=true Error: code run failed (exception): ToolCallError: cannot get required service "sessionProjections" in inactive context
...（09:43:28 前重复 16 次）

# 第二次：max -> high（第 30 轮第 1 步中改，第 2 步首次失败）
2026-10-17T12:22:35.642Z model/selection  {"model":"deepseek-flash","reasoningEffort":"high"}
2026-10-17T12:22:38.642Z request/header   {"model":"deepseek-flash","reasoningEffort":"high"}
2026-10-17T12:22:42.880Z tool/call name=run_code
2026-10-17T12:22:43.608Z ptc-dispatch name=ops_bash isError=true
2026-10-17T12:22:43.674Z tool/result isError=true Error: code run failed (exception): ToolCallError: cannot get required service "sessionProjections" in inactive context

原始日志含用户对话内容，不适合整份公开；如果需要，我可以提供更多脱敏后的片段。

历史会话扫描

扫描 ~/.dsh/sessions 下全部会话，出现过该错误的如下（备注里的时间同样是 UTC，方便直接对照 session log）：

日期	会话	错误次数	备注
2026-09-12	session-484c9ddf	6	17:22:48 强度改 max → 17:23:19 首次报错
2026-09-29	7d50bea4	1	—
2026-10-12	session-ce82e74a	1	—
2026-10-14	session-368a5643	17	—
2026-10-16	session-b114ab7f	40	—
2026-10-17	1268315f / 38e0a3c7 / b39032fb / 55165f3f	37 / 69 / 28 / 27	两次均紧跟改强度（8 秒内）

权限切换与插件重组合的观察

以下为本地时间（CST）。

• 2026-10-17 18:07（CST）：切权限预设到 auto，同一分钟内启用 MemOS 触发重组合（cordis.yml 被重写），随后整轮工具调用 aborted before dispatch；切回 workspace-write 后恢复；
• 2026-10-15 10:01（CST）：回合中切 preset 到 auto，立刻出现 Auto review of tool "write" failed 并连续失败，切回预设后恢复；
• 2026-10-17 15:52（CST）：只启用插件、没有改模型，会话立刻开始报同样的 inactive context。

[argszero]

Both error lines are disposal symptoms, not a missing plugin

This is the same failure family as #9812 (and #8857), and the two messages in your log are not two bugs. Neither of them says "a plugin is missing"; both say "something that used to be loaded is not loaded any more". Reading them literally is why this report keeps getting filed as a plugin-installation problem.

cannot get required service "sessionProjections" in inactive context — vendor/cordis/src/reflect.ts:156-166, message at :160. The lookup starts at the calling context and walks up one fiber at a time (:157 fiber.store?.[prop], then :165 fiber = fiber.parent.fiber). It stops at the first fiber that declares the name in its inject and has no implementation, and throws there (:159-161) — deliberately, without falling through to a grandparent that might still provide it. So the true sentence is: this reader's fiber is not ACTIVE. A fiber that declares a dependency it cannot resolve is a fiber that has been unloaded, or that never finished loading. It is not a missing npm install.

permission: permissions session projection is not registered — packages/interaction/permission-presets/src/index.ts:329-330. sessionProjections.register() is a Cordis effect on the calling fiber (packages/session/session-projection/src/index.ts:273), ref-counted by key (:282, :288-289): the unit exists exactly while at least one registering fiber is loaded, and the key is deleted when the last one unloads. stateOf() (:320) returns undefined only when the key is absent. So this line says: at that instant the registry held no permissions unit.

Both are therefore the same event seen from two readers — one host reader (the permission preset service) and one agent-scoped reader. Your own evidence already rules out the whole-host story: #9812's follow-up has healthy sessions in the same process, same profile, minutes apart, and the wedge is per session. That is exactly the shape of one agent scope going down, not of the plugin tree being rebuilt.

Why turn/end still says completed

Nothing cancels a turn when the context underneath it is torn down. The Agent object keeps its own promise chain, so turn/end is appended normally; only the next dispatch that needs a service goes through the dead context. That is why "turn/end completed" and "no tool can run" are not contradictory, and why a restart or a preset switch "rescues" the session — both give it a fresh agent context.

Where the permanence comes from

The reconciliation that follows a config write swallows the interesting failure. vendor/include/src/index.ts:197-200 (the Include that owns your profile patch list) vetoes the fiber restart and applies the new patch list as a row-level diff:

this.root.update(this.applyPatches(this.data!, config.patches)).catch((error) => {
  this.ctx.logger.warn(`config update at %C failed`, this.filename)
  this.ctx.logger.warn(error)
})

The file-watch path repeats the same shape at :282-285. A rejected root.update() is logged and dropped: rows already unloaded stay unloaded and nothing retries. That is the difference between a transient reload window (calls fail for a second, then recover — which is what #9812's deliberate write probe measured) and a session that never recovers. It also explains the per-session pattern in #9812's follow-up: rows are updated individually, so a failure halfway through leaves some subtrees down and their neighbours healthy.

The decisive next step — please grep the desktop log, not the session log

The session log records the symptom; the host log records the cause. At the wedge time, these three lines, in this order of usefulness:

1. config update at … failed — names the file and carries the rejection underneath it (include/src/index.ts:198-199);
2. agent preset <id>: … — an agent preset mount failure, logged at packages/preset/agent-preset-registry/src/index.ts:119 when mountPreset throws;
3. a duplicate-registration error (… is already registered) — a row that unloads and reloads can hit this when the replacement instance registers before the old disposer ran.

Whichever row those name decides the remaining question, which is the only one still open between your report and #9812: (a) a row restarted and its dependents never came back, or (b) a preset generation swap took a live agent's scope with it. Your two reports describe (a) and (b) respectively, and the log line distinguishes them without a reproduction.

What I am not claiming

I have not reproduced the wedge, so I am not naming the row. What the source does support is narrower than the original hypothesis: a write to cordis.patch.yml is a row-level update, not a tree rebuild, which matches your own negative probe, and the always-fatal-if-written story is not what the code does. The two messages above are precise, though — the error text is simply misleading, which #7900 complains about as well.

What the repair looks like upstream

1. Do not swallow the reconcile rejection. Both call sites catch and warn; make a failed row update a visible, retryable state instead of a half-applied tree.
2. A turn must not survive its context. When the fiber that backs a running agent is unloaded, the turn should end with a named cause; the present behaviour turns one disposal into an unlimited stream of service errors, each of which looks like a different bug.
3. A settings write should not restart rows the user did not touch. configEditor.edit() writes a whole config object back, so a row whose effective config is materially unchanged can still be rewritten and restarted — which is how a change to one setting reaches rows that have nothing to do with it.

To be explicit about the contribution shape: this is not fixable by a plugin, and I am not proposing one. A plugin's hooks run through the same context; once the fiber chain that provides the service is gone there is nothing a plugin can hand back to a caller holding a stale reference. The gap is in core disposal/reconciliation semantics, so it belongs in the repository.

[VillagerUncle02]

谢谢分析，两条报错都指向「东西曾经加载过、现在没了」，这个解释和我们看到的现象能对上。补三件事：发布之后又抓到两次复现、宿主机日志的获取限制，以及想请教怎么拿到你要的那三行。

1. 发布后又复现了两次，都符合「上一轮结束后改配置，下一轮首次工具调用失败」

会话 A（21:23 CST，原报告里的那个会话）：

• turn 32 结束 21:23:26；
• model/selection reasoningEffort=max 21:23:31（轮次结束后）；
• turn 33 开始 21:25:50，request/header 用上 max 21:25:52；
• 21:25:59 第 1 步首个工具调用失败：sessionProjections in inactive context；21:26:04 再次失败。

会话 B（21:42 CST，新开的会话）：

• turn 1 结束 21:42:35；
• model/selection reasoningEffort=max 21:42:45；
• turn 2 开始 21:42:54，request/header 21:42:56；
• 21:42:58 首个工具调用失败，同样报 sessionProjections in inactive context。

两次都是「turn/end 之后改设置 → 下一轮第一次调用就失败」。之前贴里的第二次是轮次内下一步失败，规律一致：失败的是重建之后的下一次请求。

2. 这个桌面版拿不到 host 日志

我们按建议去抓 Desktop 的宿主日志，结论是这版（0.2.1-rc.2）不落盘：

• %APPDATA%\@deepseek-ai\dsh-desktop\logs\ 里只有崩溃时的 crash-<time>-main.log，没有持续运行的 host 日志；
• 主进程只把 host 的 stdout 接到自己的 stdout；host 的 stderr 被收进一个 64 KB 内存缓冲（resources/app.asar/lib/main.js 约 3813-3815 行），只在 host 崩溃时写进 crash report；
• cordis logger 的输出走的是 stderr，所以 config update at … failed、agent preset … 这类行不会出现在任何可捕获的文件里。

我们确实抓了一次 host stdout（%TEMP%\dsh-host-capture-*.log，约 85 KB）。里面只有 MemOS 和启动日志，没有任何 cordis 行；之后两次尝试复现都没触发（可能 row update 失败本身有概率性）。

3. 想请教怎么拿到那三行

• 这版有没有打开 host stderr / 详细日志的环境变量、启动参数或配置？
• 如果没有，是否接受「会话级证据 + 上述捕获限制」？或者你们建议直接跑 headless host（绕过 desktop 的 stderr 缓冲）来复现？
• 需要的话我们也可以换一种启动方式，把 host 进程的 stderr 直接重定向到文件，再复现一次，把 config update at … failed 那几行提出来。

4. 另一个可能相关的观察

同一 host 上，会话切到「自动审查」预设后，工具调用全部 aborted before dispatch，切回完全访问立刻恢复；期间没有任何 approval/asked 事件。看起来也是某个 integration/agent scope 关闭后没有重建。不确定这和 (a)/(b) 是不是同一机制，仅作线索供参考。

[willlllliams]

独立样本：换模型后第 6 个事件即出现 inactive context；5 个会话共 47 次 aborted before dispatch

本文已就地更正。 初版有两处说法经复算后不成立（inactive context 的预设归属、两处计数），已在正文直接修正，不再保留错误版本。

同版本复现了本贴的核心因果链，补充三组本贴尚未量化的数据：换模型到首个失败的精确间隔、故障在 auto 预设下的集中度、以及**auto 下另外两条与本贴症状不同但同源的失败路径**。

环境

• DSH Desktop 0.2.1-rc.2，Windows 11 x64，profile desktop，session format v4
• ⚠️ 与本贴作者不同：本机装有第三方插件（dsh-ops 提供 ops_* 前缀工具、若干 panel-mcp-*）。这点先说在前面，[Bug] 运行时重载导致权限选择器消失与工具永久失效：permission-presets 与 auto 预设的依赖死锁（0.2.1-rc.2 仍复现） #10040 评论里也提醒过不要假定单一根因。下列结论涉及的 permission-presets / auto-review / tool binding 均为第一方包，但样本不是纯净组合
• provider 混用官方 deepseek-account 与社区中转，下文会标注

1. 换模型 → 首个失败：6 个事件 / 5.5 秒

会话 A（06fc3cbc，脱敏后仅保留事件类型、UTC 时间、路由）：

19:35:52.167Z  request/header  reason=change  route=deepseek-account/deepseek-flash   ← 换模型（此前为社区中转 + flash-free）
19:35:52.172Z  request/context
19:35:52.180Z  session/title-llm-request
19:35:52.949Z  session/title
19:35:57.642Z  assistant/message
19:35:57.643Z  tool/call       name=read
19:35:57.644Z  tool/result     isError=true
               Error: cannot get required service "sessionProjections" in inactive context

reason=change → 首个失败之间只有 6 个事件 / 5.477s，中间没有任何 turn/end、没有 dispose、没有 model/selection 之外的信号。这印证了本贴「重建发生时正在执行的请求不受影响，失败的是它之后的下一次模型请求」——这里连下一次请求的第一个工具调用就挂了。

随后本会话 inactive context 累计 16 次，turn/end 依然是 {"kind":"completed"}，属于本贴描述的僵尸会话。

2. 故障集中度统计（去重后 5 个唯一会话）

会话	aborted before dispatch	inactive context	Auto review ... failed
84ddee67	18	18	0
5823b939	10	7	0
72affdcb	10	0	1
06fc3cbc	9	16	2
f35f9d74	0	4	4
合计	47	45	7

这两类错误的预设归属不同，必须分开说：

• aborted before dispatch + Auto review ... failed（共 54 次）：53 次在 preset=auto，1 次在 danger-full-access（某会话切走后的余波）。即基本可视为 auto 专属
• inactive context（共 45 次）：与预设无关，跨预设出现 —— auto 27 次、无 preset 事件阶段（session 起始）15 次、workspace-write 3 次

即 inactive context 的 45 次里有 18 次（40%）发生在非 auto 下，不能说它只与 auto 共存。

对照片段（只对 aborted before dispatch 有效）：

会话	workspace-write 片段	其中 aborted
5823b939	9 次	0
84ddee67	50 次	0（但有 3 次 inactive context）

即 workspace-write 下不出现 aborted before dispatch，但可以出现 inactive context。

这与本贴的 aborted before dispatch 表现一致，也与 #10041 独立统计（125 份日志中仅 2 份含 ABORTED_BEFORE_DISPATCH，且都在 auto 下）方向一致。

3. auto 下的另外两条失败路径（与本贴症状不同，但同源）

这两条容易被误并入 inactive context，故单独列出。

(a) 审查器找不到被调用的工具 schema —— 2ms 同步抛错，不发 LLM 请求

Error: Auto review of tool "bash" failed; its body was not executed:
auto-review: the pending native tool schema is missing or ambiguous

实测该会话 request/header 下发 200 个工具，其中不含 bash（只有 ops_bash）。nativeAction() 要求「恰好一个同名 schema」：

const schemas = candidates.filter(s => isRecord(s) && s['name'] === exec.name)
const [candidate] = schemas
if (candidate === undefined || schemas.length !== 1)
  throw new Error('auto-review: the pending native tool schema is missing or ambiguous')

模型一旦调用未注册的工具名，审查器自身先抛错，整个调用被 failed() 转成 deny。一个上游健壮性问题：这里更适合放行给下游、由 tools 层返回正常的 unknown-tool 错误。

(b) 审查器复用会话模型 → 免费模型下 429 直接变成工具禁用

classifyRisk() 从 session.requestHeader() 取 provider/model 作为审查路由，即审查请求跑在当前选中的同一个模型上。实测 preset=auto + 社区中转的 flash-free 模型时，连续 4 次：

Error: Auto review of tool "edit" failed; its body was not executed:
auto-review: reviewer ended with error RATE_LIMIT: 429: {"type":"FreeUsageLimitError","message":"Rate limit exceeded..."}

切成官方 deepseek-account/deepseek-flash 后，同一会话后续 65 次 tool/result 中 0 次出现该限流错误（其中 4 次为其它类型错误，与限流无关）。这与 #1455（zen 免费档 UA/限流）同源，但对本贴的意义是：auto 会把「模型不可用」放大成「所有工具不可用」，因为审查失败走 failed() → deny，不会降级成普通审批。

4. 一个可用于归因的耗时判据

区分这几类失败时，耗时比错误文案可靠：

失败	耗时	是否发过审查 LLM 请求
Auto review ... schema is missing or ambiguous	~2ms	否，同步查表即抛
Auto review ... RATE_LIMIT / TIMEOUT	137–267ms（单次尝试，不重试）	是
aborted before dispatch	1.0–3.6s（p50 1377ms，46/47 >100ms）	是，审查往返后才 cancel
inactive context	不定	—

前两条在本次样本里只出现在 auto；aborted 也基本只出现在 auto；inactive context 与预设无关。

5. 与已有报告的关系

• 本贴（[Bug]回合运行中改模型/思维强度/权限，会让会话所有工具调用失效（sessionProjections in inactive context） #10007）：补上「换模型 → 首批失败」的精确间隔（6 事件 / 5.5s），以及 auto 预设的故障集中度
• [bug] Auto review: every remaining tool call returns "aborted before dispatch" after a mid-turn /permission auto switch #10041：补上 aborted 的耗时分布，以及它与 schema 错误 / 限流错误的区分判据
• [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 #9812：本机 45 次 inactive context 中 turn/end 同样是 completed，确认不是 dispose，属于同一僵尸态
• OpenCode zen 免费模型（big-pickle）在 DSH 中必现 429 FreeUsageLimitError（附修复补丁） #1455：补上「审查器复用会话模型」使 429 直接放大为工具禁用的链路

6. 复核方法

所有计数来自 ~/.dsh/sessions/<id>/session.v4.jsonl.zstd 的解码。注意该文件是逐次追加的 zstd 帧串联，单次 zstd -d 只能解出第一帧；需按 28 b5 2f fd magic 分帧后逐帧解压，否则会漏掉绝大部分事件（我一开始就只解出 201 字节 / 144KB）。解码后按 tool/result 的 message.isError 与文本指纹分类即可复算上表。

如需，我可以贴出脱敏后的提取脚本。

---

补充一句关于 #10040：那边的第三条回复已经给出 Cordis vendor/cordis/src/fiber.ts 分组清理「成功链跳过后续 disposer」的源码小修（含 14 项回归、反向应用验证），并明确标注尚未获得维护者确认、未部署。本贴的 inactive context 与那个「旧 hook / 旧绑定未撤销」是同一族问题，但清理小修单独并不能恢复 Auto bootstrap 失败，二者不宜互相替代。

[willlllliams]

补充证据：一种「session 出生即坏」的形态，以及宿主日志的可得性

说明：本文原为对上一条的勘误。相关更正已直接并入上一条正文（不再保留错误版本），故本节只保留勘误过程中新发现的证据。

1. 上一条已就地修正的内容（供对照，不重复展开）

• inactive context 不是 auto 专属：45 次中 auto 27、无 preset 事件阶段 15、workspace-write 3，即 40% 在非 auto 下
• 「workspace-write 期间 9 次调用 0 故障」只对 5823b939 成立；84ddee67 在 workspace-write 段 50 次调用中有 3 次 inactive context
• 切换模型后应为 65 次 tool/result（61 成功 + 4 其它错误），其中限流类 0 次

2. 新证据：84ddee67 在 session 建立时就已失效

该会话的现象形态与本贴其他样本都不同——它不是"运行中改配置触发重建"，而是从一开始就不通。

seq 15   16:24:14.610Z  tool/call   name=ops_bash   turn=1     ← 该 session 的第一个工具调用
seq 16   16:24:14.611Z  tool/result  isError=true
         Error: cannot get required service "sessionProjections" in inactive context

seq 111  16:28:44.355Z  permission/preset  workspace-write     ← 第一个 preset 事件，比首个失败晚 4 分半

关键点：首个工具调用失败（seq 16）早于该会话里任何 permission/preset 事件（seq 111）。

量化：seq 111 之前的 tool/result 共 15 条，全部 isError（seq 16E 18E 23E 28E 33E 38E 43E 48E 61E 66E 79E 84E 89E 102E 104E），随后在 workspace-write 段又有 3 次，之后切到 auto 又出现 18 次 aborted before dispatch。

这给 #10041 评论里提出的两种可能增加了第三种形态：

• (a) 某行 restart 后 dependents 没回来
• (b) preset 换代带走了 live agent 的 scope
• (c) scope 压根没建立成功，session 就开始执行了

(c) 的特征恰恰是「失败早于任何配置事件」，这与 (a)/(b) 依赖一次既有配置变更来解释的模型不同。若上游已有 (c) 的样本，请忽略本节。

3. 宿主日志：本机与另一位报告者结论一致，该检查在本版不可行

核实本机 %APPDATA%\@deepseek-ai\dsh-desktop\logs\：

• 只有 crash-<time>-*.log，无持续运行的 host 日志
• 本机最新一个为 2026-10-16 15:28，早于本次故障（2026-10-18）
• 因此 config update at … failed / agent preset <id>: … 这几行在本机不可得

也就是说，「去 grep 桌面端宿主日志」这一步在这一版桌面端上物理上做不到。若上游希望拿到这三行，需要先提供把 host stderr 落盘或可导出的开关；我可以配合复现。

4. provider 说明（避免误读）

本机混用官方 deepseek-account 与社区中转。第 2 节的 84ddee67 全程为官方 deepseek-account/deepseek-flash，未使用中转，可作为纯官方路由下的样本参考。