[Bug] Mounting dsh-hooks-claude-code paralyzes the host: every tool call dies with "agent.session.events is not iterable"

[woodmanfany-francis]

Impact

Mounting the official hooks bridge (@deepseek-ai/dsh-hooks-claude-code, activated via patch insert: [{id, name, config:{configPath}}]) makes every tools. call in every live session fail* with:

agent.session.events is not iterable

The host cannot self-recover — the broken channel is the one agents use. Recovery requires the operator to strip the patch block out-of-band and restart.

Reproductions (both on harness 0.1.2-rc.1)

1. npm @0.0.1-rc.5 (2026-09-05)
2. version-matched bundled @0.1.2-rc.1 (2026-09-07) — identical signature

Since the version-matched bundled copy reproduces it too, version skew is NOT the cause; the plugin's session-event iteration is incompatible with the running host surface.

Aggravating factor: patchReload hot-mounts on save

Editing cordis.patch.yml hot-applies the moment the file is saved — "edit now, restart later to apply safely" is not a thing. The paralysis begins before any restart.

Expected

Activation should fail closed: if the plugin cannot iterate the session event surface, log and no-op — never wrap every tool call into an exception.

Proposed guard

At activation, probe Symbol.iterator on agent.session.events once; refuse to mount (with an operator notification) when absent.

---

###附: small companion FR
approval/decided reports outcome (allowed-once|rejected|cancelled) but no field says who answered — with multi-channel answerers (GUI + IM card on one host) we cannot reconstruct approver identity from logs. Suggest an optional answeredBy threaded from the waterfall answerer. Happy to provide more context from our setup.

[argszero]

Great report — the reproduction detail (version-matched bundled rc.1 still failing) is what cracked it. I traced this against the repo history and the conclusion is different from "the plugin is incompatible with the host surface": the repo source is already fixed; the artifacts you ran embed a stale bridge build.

What the repo history shows:

1. The agent.session.events iteration was in hooks-claude-code's lastTurn() helper:

   const last = [...agent.session.events].findLast(e => e.type === 'turn/start')

   (present at dsh-v0.1.2-alpha.1, packages/hooks/hooks-claude-code/src/index.ts:312).

2. It was removed 2026-08-19 by commit 1a72ae202a ("refactor(session): migrate host state reads to projections") — lastTurn(exec.agent) became lastTurn(ctx, exec.agent) reading sessionProjections, and the plugin's inject gained 'sessionProjections'. Master's lastTurn (index.ts:310-313) reads boundary.lastTurn from the projection — no event iteration anywhere.

3. The dsh-v0.1.2-rc.1 tag source is clean — git grep session\.events dsh-v0.1.2-rc.1 -- packages/hooks/hooks-claude-code/ returns nothing. The current Session surface has no .events member at all (it exposes snapshotEvents()/ownEvents()/eventAt(); verified in the public declaration too) — so any bridge still calling .events fails exactly as you describe, on the tools/pre-execute path (every tool call), because lastTurn runs there.

Conclusion: since both the rc.1 tag source and master are free of .events, your npm @0.0.1-rc.5 (2026-09-05) and the bundled rc.1 copy must have been built from pre-Aug-19 bridge code — a stale-artifact situation (published/bundled plugin lagging the repo source that already carried the fix). Version-matched core doesn't exclude this: the bundle can pair a new core (which dropped .events) with an old embedded bridge.

To confirm: run the repo at the dsh-v0.1.2-rc.1 tag or 0.1.3-alpha.1 (d347e70390) — the error should disappear, since both carry the migrated bridge. If it still fails there, that would point somewhere else (and a stack trace / thrower module path would help).

On your fail-closed activation guard: reasonable as defense-in-depth (a one-time Symbol.iterator/capability probe at mount would have surfaced this class early — the same "pre-stable API removed without signal, consumer breaks at runtime" pattern as the plugin↔core drift family). It doesn't replace the artifact fix, but it converts "host paralyzed with no self-recovery" into "plugin refuses to mount with a clear notice", which is a strictly better failure mode. Worth proposing upstream as a general consumer-side capability guard.

On the companion FR (approval/decided lacks answerer identity): verified — the event payload is { id, outcome } only (interaction/user-approval/src/types.ts:55-61), and the append site (index.ts:224) records nothing about who answered. The approval dispatch is first-claimant-wins across registered answerers (the #5236 ownership-determinism discussion), so the deciding answerer is knowable at decide-time — threading an optional answeredBy (answerer id + channel) into the audit event would let multi-channel deployments reconstruct approver identity from logs. This is a small core change (the event vocabulary is declared in core types, so it can't be done plugin-side); worth tracking for when upstream Issues reopen, and the #5236 thread is the natural place to propose it.