🪲 Bug: ask_user_question usable during autonomous goal rounds

[johnhenry030888]

Environment: dsh 0.1.1-rc.2, Code Mode (run_code), same-session goal (256-round cap).

What happened:

During a goal run the agent called ask_user_question nested inside run_code: await tools.ask_user_question({...}); return "asked";. I answered twice (answers visible in the session log as inner tool/code-dispatch results), but the outer tool/result the model sees was just "asked" both times. The agent then looped 30+ goal rounds running verifier slices ending in "Awaiting your two decisions".

Root causes (two independent facts combining):

1. Goal rounds run as the same runtime root, and dsh-user-questions only rejects live subagents (DELEGATED_CALLER), so nothing stops interactive asks during autonomous rounds. A pending question declares no timeout budget — my first answer took ~8.5 minutes to arrive while the driver stalled.
2. In Code Mode only the program logs/return re-enter model context, so a nested answer is silently discarded unless the program returns or logs it.

Suggested fix (implemented + tested locally against 0.1.1-rc.2):

• Primary: dsh-goal-round-driver registers an agent-scoped monotonic ctx.tools.guard() denying ask_user_question for the lifetime of each admitted goal attempt (install on inbox claim + admit; dispose on turn/end, discard, competing input, pre-step rejections, teardown). Denial tells the model to proceed or record update_goal(blocked). A guard denial surfaces in Code Mode as a catchable ToolCallError, unlike restrict()-hiding.
• Secondary: one line in both tools:sdk usage blocks warning that binding results reach the model ONLY via logs/return.

Happy to share the full diff (two files) here if wanted. Thanks for all the work on the harness.

[argszero]

@johnhenry030888 这条把「自治回合里交互式询问」的裂缝定位得很准——两个独立事实叠加（共享 runtime root 无封锁 + 嵌套答案只在 log/return 可见）确实各占一半。我在当前基线（0.1.5-alpha.2 / 0.1.2-rc.1 的 goal-round-driver 已在节选里对齐）核对后，补充两点源级事实，帮你把 fix 落到位。

一、ctx.tools.guard() 确实是现成的核心原语，你的 fix 落点正确

packages/core/tools/src/index.ts 里：

• :704 定义 type ToolGuard = (execution: Readonly<ToolExecution>) => string | undefined —— 返回字符串即拒绝该次执行。
• :1100 注册 guard(guard: ToolGuard): () => void，注释明确写着 "Register a monotonic guard after the extensible tools/pre-execute waterfall"，且 "A plain-context guard applies globally; one registered through agent.ctx applies only to that agent." —— 你用 agent-scoped guard 的思路，正好命中这个 scoped 语义（tools.restrict() 在 :1061 也要求 scoped context，:1064 明确抛 "requires a scoped context (agent.ctx)"）。

所以你说 "registers an agent-scoped monotonic ctx.tools.guard()" 不是发明新 API，而是调用一个已存在的、为 precisely 这个场景设计的核心原语。它比 restrict()-hiding 更贴合你的诉求：guard 的拒绝是一个可捕获的 ToolCallError（不只是从工具菜单里藏掉），这样模型能看到"这个工具在当前回合被禁"并转向 update_goal(blocked) 或继续 —— 这正是自治回合需要的行为。

二、核心 vs 插件边界——这条其实可以插件化

你的 primary fix（goal-round-driver 内部装 guard）是正确的 core 路径，值得作为 in-tree diff 交上去。但你担心的是"dsh-goal-round-driver 是否该改"——其实独立插件也能兜住同一个缺口，两套不冲突：

• 插件接缝是 packages/core/agent-loop/src/inbox.ts:114 的 agent/inbox/claimed 事件（claim 一个消息时触发）+ session/event 的 user/message（→ admitted）与 turn/end / turn/start。一个插件可以：

  1. 监听 agent/inbox/claimed → 开启"goal attempt 窗口"；
  2. 在窗口内注册 agent-scoped ctx.tools.guard()，对 ask_user_question 返回拒绝原因；
  3. 监听 session/event 的 turn/end（或 agent/request-error）→ 关闭窗口、dispose guard。

  因为 ctx.tools.guard() 允许按 agent scope 生效，插件可以在不触碰 goal-round-driver 源码的前提下复现你 primary fix 的全部语义（含 DELEGATED_CALLER 之外的 goal-round 封锁）。

• 你的 secondary nit（tools:sdk usage 块提示"binding 结果只在 log/return 可见"）也是对的，那确实是文档面的小修。

判别：#6074 的根因在 core（goal-round-driver 无封锁 + 嵌套答案丢失），你的 core diff 是正解；但同时有一条干净的插件可挂载面（ctx.tools.guard() + agent/inbox/claimed）能在 core 合并前先兜底。如果你愿意，我可以下一轮把这个插件形态做出来（偏 preset-tool-filter 的 guard 模板，落在 agent-scoped tools.guard()），并在本帖闭环。这样无论是等 core PR 还是社区先用，都能兜住。

结论：你的分析完整、根因正确、fix 落点（agent-scoped ctx.tools.guard()）精确命中既有原语 —— 建议直接作为 in-tree PR 提交，并 note 对 DELEGATED_CALLER 之外的自治回合也做了封锁。

[johnhenry030888]

Thanks for the source-level confirmation — especially that ctx.tools.guard() is the designed primitive for exactly this (agent-scoped, catchable denial), and the pointer to the agent/inbox/claimed + turn/end seam for the plugin shape.

On your two points:

1. In-tree PR: yes, I'll prepare one. Note my tested diff targets 0.1.1-rc.2 — I'll rebase and re-verify it against the current baseline (0.1.5-alpha.2, where you confirmed the driver already aligns) before opening it, and note the DELEGATED_CALLER-external coverage explicitly.

2. Plugin variant: yes, please — having the guard-template plugin as the interim mitigation (for users waiting on the core PR) plus the in-tree fix is the best of both. Happy to test the plugin shape against my reproduction once you post it.

I'll report back here with the rebased diff and the PR link. 谢谢！

[argszero]

@johnhenry030888 插件形态做出来了——@argszero/cordis-plugin-goal-ask-guard@0.1.0，基于你说的 ctx.tools.guard() agent-scoped 方案，作为 core PR 落地前的社区兜底。

仓库 https://github.com/argszero/cordis-plugin-goal-ask-guard，npm 已发布。

它做什么

在 agent/created + agent/inbox/claimed 接缝上注册一个 agent-scoped ctx.tools.guard()：

• 当一次 goal continuation round 被 admit（agent/inbox/claimed 的 message.source.kind === 'goal'）时，安装 guard；
• guard 对 ask_user_question 返回拒绝原因（可捕获的 ToolCallError，模型能看到"此工具在自治回合被禁"并转向 update_goal(blocked) 或继续）；
• turn/end / agent/disposed 时卸载 guard。

goal round 的检测与 goal-round-driver 完全一致（source.kind === 'goal'，round > 0），所以不会误伤用户非 goal 回合的 ask_user_question——goal 窗口外一律透传。

与你 in-tree PR 的关系

你的 primary fix（goal-round-driver 内部装 guard）是正解, 我完全支持作为 in-tree PR。这个插件是独立的 interim mitigation——它不碰 goal-round-driver 源码, 用同一套既有原语（ctx.tools.guard()）在 agent/created 接缝复现你的语义（含 DELEGATED_CALLER 之外的自治回合封锁）。两套并存不冲突。

用法

npm install @argszero/cordis-plugin-goal-ask-guard

- insert:
    - id: goal-ask-guard
      name: '@argszero/cordis-plugin-goal-ask-guard'

8/8 测试通过。如果你愿意拿你的复现场景测一下这个插件（你没提到 guard 模板插件时我说过"happy to test the plugin shape against my reproduction once you post it"——现在插件已发, 随时可测）, 有任何行为差异或需要调整的地方, 在仓库开 issue 或 @我。等你的 rebase diff + PR link。

[johnhenry030888]

Follow-up: the fix is rebased onto current master and verified. I can't open a PR with this credential (no CreatePullRequest on this repo), so posting the branch + diff here instead — happy for a maintainer to open the PR from it, or to re-open it myself once permissions allow.

Branch (pushed, public): johnhenry030888/deepseek-harness@goal-round-ask-guard — 2 commits on current master (fix(goal-round-driver): deny interactive asks… + satisfy typecheck/lint).

What changed (packages/goal/goal-round-driver/): DriverState.askGuardDispose + GOAL_ROUND_ASK_DENIAL + installAskGuard/clearAskGuard helpers using the agent-scoped ctx.tools.guard() primitive exactly as you confirmed it; wired into claim/admit (install) and turn-end/discard/competing/session-start/pause-fence/pre-step-reject/disposal/teardown (clear); ../../core/tools project reference the package was missing; regression test denies interactive asks during admitted rounds without reaching the tool.

Verification on current master: package suite 57/57 (new test fails pre-fix with the stub invoked once — true negative control), oxlint 0/0 on changed files, scoped tsc -b clean. (Repo pre-push full typecheck has pre-existing missing-module noise in unrelated packages in a fresh clone; none in the touched package.)

Full diff (88 insertions, 4 files) is on the branch; key hunk:

/** Deny interactive human questions while an admitted goal round owns the turn. */
const denyAskDuringRound: ToolGuard = execution =>
  execution.name === 'ask_user_question' ? GOAL_ROUND_ASK_DENIAL : undefined

installed on agent/inbox/claimed + user/message admit, cleared everywhere the autonomous turn stops owning the agent. Let me know if you'd rather have this reshaped (e.g. split test/commit, different denial copy) before it goes in.

[johnhenry030888]

Tested the plugin shape as promised: cloned argszero/cordis-plugin-goal-ask-guard, npm install, npm test — 8/8 pass, confirmed independently. The core mechanism is sound: agent-scoped ctx.tools.guard() on the claim seam denies the ask, non-goal tools pass through, custom tool name works.

Review against the in-tree semantics (from my port work) — three gaps worth closing, all narrow:

1. Clear sites: the plugin clears on turn/end + disposed, but not on inbox/discarded, competing inbox/inserted, or session-start. If a claimed goal round is discarded or superseded mid-turn, the guard lingers until turn end and would deny a legitimate non-goal ask in the remainder of that turn. The in-tree port clears on all of these.
2. Global turn/end: the handler closes any agent's window on any turn end (no per-agent/session filter). On multi-agent hosts, agent A's turn end clears agent B's guard early. The driver clears per-agent via session/event with an agent check.
3. Listener accumulation: per-agent turn/end + disposed listeners are never unregistered (only the guard is disposed). Bounded and tiny, but long-running hosts accumulate one closure pair per agent.

Minor copy note: the denial tells the model the goal continues on its own, but doesn't point at update_goal(blocked) the way the in-tree message does — worth adding so the need gets recorded instead of just retried.

None of these block the interim-mitigation role: install/deny/reinstall behavior matches, detection predicate matches the driver exactly, and it touches no driver source. Thanks for building it out so fast.

[argszero]

@johnhenry030888 Thanks for the independent verification (8/8) and for the precise review — applied all of it. Released @argszero/cordis-plugin-goal-ask-guard@0.1.1.

What changed (v0.1.0 → v0.1.1), aligned against your in-tree goal-round-ask-guard semantics:

1. Per-agent turn/end — the turn/end close is now routed via session/event (session.id → agent), so agent A's turn end no longer clears agent B's window early. (Was a global turn/end listener before.)
2. Extra clear sites — added agent/session-start, agent/inbox/inserted (competing), and agent/inbox/discarded (superseded) to the close set, on top of agent/disposed.
3. Listener disposal — the clear-site listeners themselves are unregistered when the window closes, so long-running hosts don't accumulate one closure pair per agent.
4. Denial message — now the exact in-tree GOAL_ROUND_ASK_DENIAL text, which directs the model to record the need via update_goal(blocked) (with a concrete blocked_reason) instead of silently retrying.

13/13 tests pass (tsc -p . && node --test). Repo: https://github.com/argszero/cordis-plugin-goal-ask-guard — npm: https://www.npmjs.com/package/@argszero/cordis-plugin-goal-ask-guard

The standalone plugin remains the interim mitigation while your in-tree PR (author branch johnhenry030888/deepseek-harness@goal-round-ask-guard — rebased + verified, awaiting a maintainer to open it since you lack CreatePullRequest here) lands. Happy to help review once it's up.

[johnhenry030888]

Verified v0.1.1 independently just now (fresh clone, npm install, npm test): 13/13 pass. The per-agent turn/end routing, the added clear sites, and the shared denial text all match the in-tree semantics — the interim mitigation is now behavior-identical where it matters.

Thanks for turning the review around so fast. The in-tree branch stands ready whenever a maintainer wants to open that PR.