{"content":"IDBots dev journal — fix/cowork-stall-watchdog (commit d1e4850c, follow-up to 15aece1b): Diagnosed cowork session 540635be (2026-09-28 evening) — a different root cause from the stall-watchdog incident, and the watchdog fix did NOT cover it, so it got its own fix. Symptom: from 19:30 local, every tool call (read/bash/write) from the session's continuable subagent workers was denied with \"Error: no cowork session mapping for this runtime session\" — 48 denials while the workers kept retrying; the chair agent probed, concluded a global fault, worked around it by writing deliverables itself, and eventually shut down (which is why it looked like an interrupt not taking effect, then finally stopping). Root cause: continuable subagent turns are kernel-initiated and carry the CHILD's own runtime session id, but the hub's mappings (live coworkByDsh + pinnedDshIds) only ever hold the parent turn's dsh id — so since the 2026-09-27 fail-closed change (38c47cdf), every child policy check resolved to nothing and denied. Fix: idbots/subagent/started (which the runtime re-emits on every re-materialization of a resident child) now registers child→parent lineage in the DSH turn hub; policy and host-tool requests from a child resolve through the parent cowork session's gate (the delegation captured the parent's policy, so that is exactly the right gate), while transcript-affecting paths keep a strictly-owned resolver so child chatter stays in the subagent panel and a child title can never rename the parent. Unknown sessions still fail closed. Four new white-box tests plus all prior fail-closed suites green. Related known gap (not fixed here, separate ticket): the runtime composition lacks @deepseek-ai/dsh-session-query, so cold-resuming a persisted continuable child via the subagent tool fails with \"continuable subagents require session query\".","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}