orchestrator_send_message: parallel sends show only one consent prompt; the other blocks indefinitely with no visible prompt

[yenhernandezmkt]

Before submitting

• I searched open and closed issues and did not find a report of this problem.
• I reviewed this report and removed credentials, tokens, private paths, hostnames, and other sensitive data.

Problem

If an agent issues two orchestrator_send_message calls in parallel (in the same assistant turn), and both recipients need consent, only one consent prompt is shown. The other call waits forever on a consent select that never appears. The agent turn stays open, the user's messages only queue as steering, and nothing indicates that the session is waiting for input. The call only ends when the user cancels or interrupts the turn, which returns Cross-orchestrator communication was cancelled.

This happened first in real use: a coordinator session sent two parallel notifications to two peer sessions. One was accepted, and the other blocked the session for ~16 minutes. We then reproduced it locally in a controlled test (below).

A related usability issue makes this worse. The consent prompt preselects "Allow once", so any Enter press while the user is typing elsewhere approves the send without them noticing. In real use the user never knowingly saw a consent prompt. Some sends went through only after 1.5–7 minute delays, which is consistent with accidental approval.

Relevant code: SessionMessagingGrants.authorize() in lib/session-messaging-grants.ts awaits ctx.ui.select(...) with no timeout; it is called from orchestrator_send_message in extensions/gentle-agents.ts.

Steps to reproduce

1. Start two idle Pi sessions with gentle-pi in the same trusted local profile (peers A and B), e.g. pi in two tmux sessions under a temp directory.
2. In a third interactive Pi session S, make sure no "Allow for this session" grant exists for A or B.
3. Single send (control): have S's agent call orchestrator_send_message once to A. The consent prompt appears inline in S ("Authorize cross-orchestrator message to ?" with Reason, Message, and Allow once / Allow for this session / Deny), with "Allow once" preselected. Choosing Deny returns denied by user. This works as expected.
4. Parallel sends: have S's agent call orchestrator_send_message twice in the same assistant turn, once to A and once to B.
5. Observe: only one consent prompt is displayed. Choose Deny. That call returns denied by user, but the other call stays pending with no prompt visible. The session remains blocked until the user interrupts it.

Expected and actual behavior

Expected: each parallel send shows its own consent prompt, either one after the other or together. Or the pending consent times out or fails with an error the agent can report. The session should never block indefinitely on an invisible prompt.

Actual: only one of the two prompts is ever shown. The second orchestrator_send_message call hangs with no visible prompt and no timeout (~7 minutes in the local test, ~16 minutes in real use) until the user interrupts, then returns Cross-orchestrator communication was cancelled.

gentle-pi version

3.7.0 (git checkout 5456811)

Pi version

0.87.1

Operating system

Linux

Relevant logs or error output (optional)

Local reproduction (UTC):
14:31:13  assistant  -> orchestrator_send_message (to A)                       [single]
14:32:51  toolResult    "Error: Cross-orchestrator communication denied by user."   (prompt shown, user chose Deny)
14:32:58  assistant  -> orchestrator_send_message (to A), orchestrator_send_message (to B)   [parallel]
          (only ONE consent prompt shown; user chose Deny; session then blocked with no visible prompt)
14:39:56  toolResult (A) "Cross-orchestrator communication was cancelled."            (after user interrupted)
14:39:56  toolResult (B) "Error: Cross-orchestrator communication denied by user."

Original occurrence:
05:23:57  assistant  -> orchestrator_send_message (to A), orchestrator_send_message (to B)   [parallel]
05:40:12  toolResult (A) "Cross-orchestrator communication was cancelled."
05:40:12  toolResult (B) "Message <id> from <S> to <B> accepted for delivery; it is not a delivery or read receipt."

Possible mitigations: queue consent prompts so they are shown one at a time across parallel tool calls, add a timeout to the consent select, show a persistent status indicator while consent is pending, and/or default the selection to "Deny" instead of "Allow once".

[carlosmoradev]

Good catch @yenhernandezmkt. Having worked on the SessionMessagingGrants consent implementation in #1364, this concurrent execution race makes total sense.

There are two distinct failure modes happening here:

1. Unqueued TUI modals: authorize() calls await ctx.ui.select(...) without synchronization. In Pi's single-threaded TUI, concurrent modal prompts collide: the first prompt captures focus, while the second one is dropped or masked without rendering. The second tool call then awaits its unresolved promise indefinitely, hanging the turn.
2. Unsafe default selection: Preselecting ALLOW_ONCE at index 0 means an accidental Enter press while typing in another window can inadvertently approve outbound transmission without informed consent.

A robust fix in lib/session-messaging-grants.ts:

• Async queue / mutex: Wrap authorize() in a promise chain (private promptQueue = Promise.resolve();) so interactive prompts serialize cleanly. Crucially, re-checking this.grants.get(id)?.has(recipient) after acquiring the lock allows subsequent sends to the same recipient to short-circuit immediately if the user already granted session-level permission.
• Fail-safe defaults: Reorder decisions to place DENY first (or omit default preselection) to guard against accidental keystroke authorization.