Group peer turns are offered ask_person and message_bot, but every call is refused

[Chebaleomkar]

A group peer turn is offered ask_person (and message_bot when maxDepth > 1), but every call from it is refused.

• A Bot-to-Bot relay turn runs at depth >= 1 and is signed with that depth and no handoff claim (runBot passes depth: turn.depth).
• authoriseCoordinationRun in server/src/agents/handoff-tool.ts returns, for a run with no handoff, (run.depth ?? 0) === 0 && source.botId === run.botId. That is false at depth 1.
• So the call is refused with "This run no longer has permission to coordinate work in this conversation", and an mcp.callback_refused audit row is written.
• Meanwhile toolsForRun still offers ask_person at 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:

1. Accept depth > 0 without a handoff claim when the source thread is the Bot's own group thread and the run's initiator is a handoff.
2. Don't offer the coordination tools at depth > 0 without a claim.

Which is intended? I can send a PR for either.

[kvnloo]

I followed Chebaleomkar's report through group.ts, handoff-tool.ts, and the current remote-coordination tests.

I would avoid relaxing authoriseCoordinationRun as 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 no handoff lease 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 authoriseCoordinationRun can accept, do not offer ask_person / message_bot to it;
• keep the execution-side refusal as defense in depth;
• add a regression asserting that every schema returned by toolsForRun is 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.

[Chebaleomkar]

Going with option 2, as @kvnloo suggested: #731.

toolsForRun now asks the same authoriseRun as call and offers nothing when a call would be refused. call keeps 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.