Approving one tool call with "15 min" or "Session" registered a bypass whose
scope was *inferred* from the call's metadata: a registered category if it had
one, otherwise its MCP server. For a connector tool that meant the whole
connector — so approving `mcp__gmail__modify_message` (labelling, archiving:
what an assistant tidying a mailbox does constantly) silently un-gated
`mcp__gmail__send_message` for the rest of the conversation, straight through
the explicit `require` rule written for it. An email went out with no prompt;
the only trace was an INFO line, since bypasses live in RAM.
A human answering a card has read one call. That call is the widest thing the
click may authorise, so the scope is now always the tool itself and is never
guessed. The wider scopes stay in the enum and stay reachable through the REST
`bypass_scope` field, where naming one is deliberate.
Both fallbacks now narrow instead of widening: a scope that cannot be honoured
(a category-less tool, a non-MCP one) and an unknown scope string both degrade
to the tool, where they used to fall through to a session-wide bypass. Only a
literal "all" disables the gate session-wide.
The buttons said "skip similar requests" without ever defining "similar"; they
now name the tool.
An async sub-agent runs in a session of its own, so the rich per-session events
that draw the inline approval card never reach the chat's socket — only the
id-only inbox lifecycle ones do. A task blocked on an approval was therefore
invisible in the conversation that started it, and the only way to unblock it
was to notice the sidebar badge and go to the Inbox.
The chat already shows what it handed off. This asks the same question of the
pending items: `GET /{source}/inbox` joins them against the sessions of this
conversation's running async jobs, so "whose is this" has one answer, in the
same place `/{source}/tasks` answers it for a task. The client is left with a
list to render, not a correlation to guess. The live path adds no event — the
existing `approval_requested` / `clarification_*` broadcasts already reach every
socket of the user, and re-reading the endpoint turns a nudge into something
renderable and survives a reload for free.
The card sits above the task strip rather than in the transcript: the task that
is asking may have been started twenty messages ago, and a card that scrolls
away is a card that gets missed. One at a time, with a count of what is behind
it — a blocked task stays blocked whether or not its card is on screen, so
stacking them would trade a readable chat for a queue nobody asked to see. And
it closes: the ✕ hides the card without resolving anything, leaving the item in
the Inbox, because a panel that cannot be moved takes the chat hostage.
`InboxCardsMixin` is the cards and their resolve calls, split out of
`InboxMixin` so the chat and the Inbox render the same approval rather than two
drifting copies of it; `_afterInboxResolve` is the only thing they disagree on.
Elicitations are left out: `PendingElicitationInfo` carries no `session_id`, so
there is nothing to attribute one to a task with.
Also: an async task's context label said "CronJob:", which sends whoever reads
the approval looking on the wrong page — and now says so next to the task's
real name.
dguiducci