[bug] Auto review: every remaining tool call returns "aborted before dispatch" after a mid-turn /permission auto switch

[tianguoyan]

Environment

• DeepSeek Harness Desktop 0.2.1-rc.2 (installed 2026-10-17, app.asar package versions 0.2.1-rc.2)
• Windows 11 26H2, build 26300; Node runtime 24.21.0 (bundled)
• Profile: desktop, with @deepseek-ai/dsh-experimental-auto-review mounted (profiles/desktop/cordis.yml, id auto-review)
• Model: deepseek-official / deepseek-flash
• Session format v4
• Auto preset spec: sandbox danger-full-access, approval ask

Summary

With the experimental Auto review integration mounted, switching the permission preset to auto in the middle of a running turn put the Auto-review gate into its cancelled state. Every subsequent tool call for the rest of that turn ended as:

Error: tool call aborted before dispatch
error: { name: "AbortError", code: "ABORTED_BEFORE_DISPATCH" }

The tool bodies never executed, and the turn still ended normally (completed). Switching back to workspace-write and starting a new turn restored normal tool execution. The model/user gets no diagnostic explaining that Auto review is inactive or why the calls were cancelled.

Observed (session session-475143e5-…, desktop profile, 2026-10-18, local time Asia/Shanghai)

Timeline from the session log (format v4, session.v4.jsonl.zstd):

seq	time	event
646	00:14:16.404	approval/asked — a pwsh call requested sandbox escalation to danger-full-access; approval pending
647–650	00:14:16.841	command/run permission " auto" → permission/preset:auto + sandbox/mode:danger-full-access, command success
651	00:14:17.902	approval/decided: allowed-once; the pending pwsh call completes normally
657	00:14:19.277	runtime-context user/message shows the new danger-full-access policy
661, 667, 673, 679, 685, 691, 697	00:14:26.244 – 00:14:51.631	7 consecutive tool results (write, write, ops_bash, ops_bash, ops_bash, read, ops_bash), steps 98–104, all isError: true, error.code: "ABORTED_BEFORE_DISPATCH", text Error: tool call aborted before dispatch
704	00:15:00.792	turn/end: {"kind":"completed"} — the turn was not aborted
705–708	00:15:48.846	/permission workspace-write → preset + sandbox events
710+	00:18:04	next turn starts; tools execute normally again

Observed behavior: the switch to auto was accepted; the already-approval-pending tool call still ran; but from the next tool call on, every call in that turn was cancelled before dispatch. No approval/asked events were created for those cancelled calls.

Second occurrence (session session-29ea28b9-…, same desktop profile, 2026-10-17)

Auto preset was selected before the turn (/permission auto, 14:16:04). During turn 1, ops_bash at step 12 returned ABORTED_BEFORE_DISPATCH at 14:18:35.877 (seq 113). The immediately following events show a mid-turn tool-registry/plugin reconfiguration:

• seq 118: developer/message with {"type":"tool-removal","toolName":"ops_bash"}, {"type":"tool-removal","toolName":"pwsh"}
• seq 122: write result Error: cannot get required service "sessionProjections" in inactive context

Later tool calls in that turn and in turns 2–3 worked again, i.e. the gate recovered once the plugin scope settled.

Evidence that this is Auto-specific

Local scan of 125 v4 session logs on this machine: only 2 contain ABORTED_BEFORE_DISPATCH results, and in both the effective preset at the time was permission/preset:auto (7 events in the session above, 1 in the second one). No such events exist under read-only, workspace-write or danger-full-access presets.

Why it happens (code pointers, master)

• packages/core/tools/src/index.ts — when a tools/pre-execute waterfall returns { kind: 'cancel' }, preparation maps it to toolAbortedBeforeDispatchResult():
  content: "Error: tool call aborted before dispatch", error.info.code: "ABORTED_BEFORE_DISPATCH", and the tool body is never invoked.
• packages/experimental/auto-review/src/index.ts — the prepended tools/pre-execute listener is the only producer of { kind: 'cancel' } for this path. It returns cancel when:
  • !accepting || lifecycle.signal.aborted before starting a review (src/index.ts:692), and
  • isAborted(lifecycle.signal) after the review provider settles (:704, :712).
• .agents/notes/implemented/feature/2026-08-28-auto-review.zh.md documents this as intended: “Provider 结算后，lifecycle abort 始终形成规范的 dispatch 前取消，包括晚到 allow、deny 或 failure。”
• The lifecycle controller is aborted only in the integration teardown (src/index.ts:733): lifecycle.abort(new Error('auto-review integration disposed')).

So once the integration's lifecycle has aborted (integration unloaded/reconfigured mid-turn), new tool calls that have no review in flight are still cancelled pre-dispatch by the listener. They are not routed back to the ordinary approval chain, and no user-visible reason is recorded.

Expected

1. If Auto review is unavailable/cancelled mid-turn, new tool calls should either
   • fall back to the ordinary approval chain (fail closed via ask), or
   • fail with an explicit diagnostic such as Auto review is unavailable; approve this call manually / a dedicated error code, instead of a generic pre-dispatch abort.
2. A permission-preset switch issued mid-turn should either be deferred to the next turn or be rejected while a turn is running, instead of leaving the remainder of the turn with silently-cancelled tools.
3. The preset command should not be able to observe a half-torn-down Auto integration (autoAdmit present while accepting/lifecycle are already in closing state).

Repro (best effort)

1. Mount the experimental Auto review integration in the desktop profile.
2. In a session, start a turn and trigger a tool call that requires human approval (e.g. a pwsh/ops_bash call with sandbox_permissions: danger-full-access); leave the approval dialog pending.
3. While the turn is still running, run /permission auto (or pick the EXP Auto entry in the permission picker) from the same session.
4. Approve the pending call and let the model continue the turn.
5. Observed: from the next tool call on, every tool result is Error: tool call aborted before dispatch (ABORTED_BEFORE_DISPATCH); the turn ends completed; /permission workspace-write + a new turn restores normal behavior.
6. Expected: the remaining calls in the turn still execute (reviewed, or prompted for approval), or the user gets a clear "Auto review unavailable" error.

Suggested workaround (user side)

Do not switch permission presets mid-turn; switch between turns. If the abort storm happens: switch back to workspace-write (or danger-full-access), end the turn, and start a new turn.

Data availability

Redacted session log excerpts (v4 JSONL) and the two aborted call ids are available on request; no tool bodies executed and no files were modified by the cancelled calls.

---

Reported on 2026-10-18. DSH Desktop 0.2.1-rc.2 is the latest release at the time of reporting (master d1b9c04067 release(dsh): 0.2.1-rc.2).

[argszero]

Your timeline, your 125-session scan and your code pointers all hold at master 687f282e86 — :692, :704, :712 and the teardown at :733 are exactly where you say. Two things I can add from the source: what the evidence actually proves, and why the broken state never recovers.

The gate is the only possible producer — confirmed structurally

PreToolDecision admits cancel at packages/core/tools/src/index.ts:611, and in production code the only three return { kind: 'cancel' } sites in the tree are auto-review's (:693, :704, :712). Every other tools/pre-execute listener in the tree returns next(), allow, deny or ask. So your log scan has a structural explanation, not just a statistical one: ABORTED_BEFORE_DISPATCH is unreachable with the Auto integration absent.

But the teardown is supposed to be self-limiting — that is the part that matters

The disposal hook is not just "abort everything":

yield async () => {
  accepting = false
  try {
    for (const session of ctx.sessions.list()) {
      if (permissionPresets.current(session) !== AUTO_PRESET) continue
      permissionPresets.set(session, 'danger-full-access')
    }
  } finally {
    lifecycle.abort(new Error('auto-review integration disposed'))
    await Promise.allSettled([...active])
  }
}

ctx.sessions.list() is every live session (packages/core/session/src/index.ts:1360), so the mid-turn session is inside that sweep. And the gate's own first test is permissionPresets.current(agent.session) !== AUTO_PRESET → next() (:689).

So a completed teardown moves every auto session to danger-full-access before it closes the gate, and cannot cancel anything afterwards. Witnessing a storm therefore proves the opposite of "the integration was torn down": the teardown stopped halfway, with the gate already shut and the sessions still resolving to auto.

Why halfway is reachable, and why it stays that way

Three facts, one line of source each.

1. accepting = false runs before the try (:726). The gate is shut before anything is repaired.
2. The sweep can throw. permissionPresets.set() resolves through permissionState() (packages/interaction/permission-presets/src/index.ts:329-332), which reads this.ctx.sessionProjections.stateOf(...) and throws when the projection is unreachable — or, from a fiber that is already draining, the exact message your second session has at seq 122: cannot get required service "sessionProjections" in inactive context. resolve() fails the same way if the preset table is already gone. A teardown that begins while the service graph is draining is precisely when those reads fail.
3. A throwing disposer skips every remaining disposer. vendor/cordis/src/fiber.ts, effect().dispose(): disposers are collected in push order and run in reverse through task = task.then(() => runDisposable(disposable)) — once task is a rejected promise, no later disposer runs at all.

The push order in that effect is stopListener (1), stopContribution (2), the async sweep (3), so on dispose the sweep runs first. Its rejection skips stopContribution and stopListener: the Auto preset stays registered, the prepended gate stays installed, accepting is false and the lifecycle is aborted. From then on :692 answers cancel for every call on any session still resolving to auto.

That state has exactly one exit: the preset stops resolving to auto (:689). That is what /permission workspace-write did at seq 705 — not the turn boundary. Two consequences you can check cheaply: with the preset left on auto, the first tool call of the next turn would also have been cancelled; and if you reproduce again, the decisive artifact is a disposal error logged between seq 646 and 661 — the sweep rejecting. That error is the bug; nothing else in the log is.

On your three expectations

1. Fail closed to a decision that names a reason — yes, and it is the sharpest of the three. cancel is the worst of the four decisions to fail shut with: denied() (:639) and askUser() (:655) both carry a reason into the transcript, while { kind: 'cancel' } renders as the bare Error: tool call aborted before dispatch with no info. A closed gate should answer deny with an explicit Auto review is unavailable; approve this call manually, or ask.
2. Deferring the preset switch would hide one trigger, not the cause. Your second session enters the same state from a reload (seq 118 tool-removal) with no preset switch anywhere near it, so any plugin reconfiguration that starts while a turn is running can land in the same half-torn state. The defect is in the teardown, not in /permission.
3. The half-torn observation is right, and :722 shows you the half that is guarded. registerAuto(() => { if (!accepting) throw new Error('auto-review: integration is closing') }) makes the preset command fail loudly, and autoAdmit still being set is what keeps auto in names() (permission-presets:285). The gate has no such check.

Minimal fix shape, in the order that matters

• Yield the session sweep first so reverse-order disposal runs it last — cleanup that can throw must never be able to skip the disposers that remove the gate.
• Sweep per session inside try/catch with a log line, so one unreachable projection cannot abandon the rest.
• When the gate is closed, return deny with a reason instead of cancel.

Your workaround stands until then, with one correction worth keeping: switching back to a fixed preset is what restores tool calls, so do that first and end the turn afterwards — not the other way round.

[willlllliams]

Independent sample: the cancels are not the closed-gate :692 path — they land after a full review round-trip

Same build (0.2.1-rc.2, Windows x64), same symptom, 47 ABORTED_BEFORE_DISPATCH across 5 sessions. Your three code pointers and the teardown ordering all check out against the shipped lib/index.js. What I can add is one measurement that I think constrains the model of the failure state, and two paths that produce this identical text but are not the gate.

1. The latency does not fit "gate already closed"

Across my whole corpus, pairing each tool/call with its tool/result:

outcome	n	p50	min	max
normal call	328	1881 ms	3 ms	—
aborted before dispatch	47	1377 ms	0 ms	4754 ms
reviewer failure (schema, synchronous)	—	2 ms	2 ms	2 ms

46 of 47 aborts took >100 ms, and the median is on the order of a full tool round-trip, not of an early return. A return { kind: 'cancel' } at :692 (!accepting || lifecycle.signal.aborted) is synchronous — it never awaits. Its latency should be indistinguishable from the 2 ms schema-throw, which is the same code path's cost floor.

So in my sample these cancels are coming from :704 or :712 (after the review provider settles), not from the closed gate at entry.

2. Within one step, one call demonstrably passed the gate

In session A, turn 1 step 1, three calls are dispatched sequentially — each tool/call is logged only after the previous tool/result:

call@19:16:26.166  working_directory  → result@19:16:27.476  dt=1310ms  ABORTED_BEFORE_DISPATCH
call@19:16:27.476  list_agents        → result@19:16:28.740  dt=1264ms  ABORTED_BEFORE_DISPATCH
call@19:16:28.741  bash               → result@19:16:28.743  dt=   2ms  Auto review ... schema is missing or ambiguous

The third call is the interesting one. It reached snapshotAutoReview() → nativeAction() and threw there, which means at 19:16:28.741 the listener had already passed both :689 (permissionPresets.current(...) === 'auto') and :692 (accepting === true, lifecycle.signal.aborted === false).

If the gate had been closed — accepting = false with a leaked listener, as the half-torn teardown would leave it — that call would have returned cancel in ~0 ms instead of reaching nativeAction. It did not. The gate was open 1.3 s after two calls in the same step were cancelled.

So either the state flips per call (which a one-shot teardown cannot produce), or those two aborts were not produced by the gate at all.

3. Two other producers render the same text

Error: tool call aborted before dispatch with error.info.code = ABORTED_BEFORE_DISPATCH is minted by toolAbortedBeforeDispatchResult() in packages/core/tools, and it is returned from at least three places, only one of which is the plugin:

• prepareExecution, before the waterfall: if (this.callerCancelled(exec)) → the caller's own signal is aborted (~0 ms)
• prepareExecution, after await this.ctx.waterfall(...) returns: if (this.callerCancelled(exec)) → waterfall-duration latency, same text
• the waterfall's decision.kind === 'cancel' → the auto-review gate

The second one is the exact latency shape I measured, and it does not require the gate to be shut — the review can complete normally (allow, deny, or throw) and the result is then discarded because the caller signal aborted during it.

This matters for attribution: the text alone cannot name the producer, and a scan keyed on ABORTED_BEFORE_DISPATCH will conflate "gate closed" with "caller signal torn down mid-call". Both are real; they have different fixes.

4. What I could not check

Your suggested decisive artifact — a disposal error logged between the last healthy call and the first cancel — is not obtainable on this build from the session log, and there is no host log to grep either: %APPDATA%\@deepseek-ai\dsh-desktop\logs\ contains only crash-*.log, newest dated before the incident. The disposal rejection you expect never reaches any persisted file. So that check needs either a stderr-to-file switch or a host log; I can re-run a repro if one is provided.

I'm not claiming my sample is your sample. Yours is a mid-turn /permission auto switch; mine has no preset switch anywhere near the storm (the preset sat at auto from 19:16:09, the first cancel is 19:16:27, and the next preset event is 19:20:06). That difference is itself worth noting: it suggests more than one route into the same abort storm, and only one of them goes through a preset write.

5. Consequence for the proposed fix

• "When the gate is closed, return deny with a reason instead of cancel" — agreed, and it removes the worst of the four outcomes. But it would not have stopped the storm I measured, because the gate there was open.
• "Yield the session sweep first so reverse-order disposal runs it last" — agreed, and it is the right shape regardless; it just isn't sufficient for a storm whose cancels originate after a completed review.
• Worth adding: make the abort attributable. { kind: 'cancel' } carries no info, so three different producers collapse into one string. A code on the decision (gate-closed vs caller-aborted vs post-review-aborted) would make the next report diagnosable from the log alone without a disposal trace.

If the caller-signal variant is also known upstream, ignore §3; the measurement in §1–2 is the part I could not find in the thread.