Repository navigation
Group peer turns are offered ask_person and message_bot, but every call is refused #716
Description
Activity
I followed Chebaleomkar's report through
group.ts,handoff-tool.ts, and the current remote-coordination tests.I would avoid relaxing
authoriseCoordinationRunas the first fix.That function has a strong existing invariant: direct runs own their source; delegated runs prove a currently leased hop. A depth>0 group peer turn has an
initiator: { kind: "handoff" }, but nohandofflease claim. Treating depth/initiator alone as authority would make the callback boundary weaker than ordinary delegated delivery.So the safer vertical slice looks like option 2:
- if a run has no authority shape that
authoriseCoordinationRuncan accept, do not offerask_person/message_botto it; - keep the execution-side refusal as defense in depth;
- add a regression asserting that every schema returned by
toolsForRunis actually callable under the same signed run.
If group peer turns are supposed to coordinate further through tools, I'd make that a second change: give the group work item an explicit signed/leased coordination claim (or equivalent authority), then offer the tools. That preserves the existing replay/lease boundary instead of special-casing “depth > 0 + handoff initiator”.
This also matches the UX invariant here: don't show a model a capability whose every call is guaranteed to fail.
- if a run has no authority shape that
Going with option 2, as @kvnloo suggested: #731.
toolsForRunnow asks the sameauthoriseRunascalland offers nothing when a call would be refused.callkeeps its own refusal and audit row for stale schemas. The regression test checks that every tool offered to a run is callable under that same run, for a leased delivery, a direct run and a group peer turn.If group peer turns should be able to coordinate, I agree that's a separate change that gives the group work item its own signed claim.
- added a commit that references this issue
on Oct 5, 2026
A group peer turn is offered
ask_person(andmessage_botwhenmaxDepth > 1), but every call from it is refused.depth >= 1and is signed with that depth and nohandoffclaim (runBotpassesdepth: turn.depth).authoriseCoordinationRuninserver/src/agents/handoff-tool.tsreturns, for a run with nohandoff,(run.depth ?? 0) === 0 && source.botId === run.botId. That isfalseat depth 1.mcp.callback_refusedaudit row is written.toolsForRunstill offersask_personat any depth.The Bot is shown a tool that always fails, and the audit trail fills with refusals nobody caused.
There are two ways to make these agree:
depth > 0without a handoff claim when the source thread is the Bot's own group thread and the run's initiator is a handoff.depth > 0without a claim.Which is intended? I can send a PR for either.