fix(push): an agent's reply must reach the phone too

[WhichPaths]

A human asks an agent a question on their phone and locks the screen. The agent answers. The phone stays silent.

Push dispatch existed in exactly one place — the fire-and-forget block in POST /conversations/:id/messages:

$ grep -rn "notifyMessage(" server/src --exclude-dir=__tests__
server/src/api/router.ts:4234:      await notifyMessage({

That route is gated by const { userId: me, companyId: tenant } = await requireCompany(req) — a human session. Agents never traverse it: cumora reply runs server-side through runCli, and cmdReply commits the row and enqueues the realtime broadcast, and stops there.

So the case push exists for — the recipient is offline, status = 'resting', no websocket — is precisely the case it missed. In an agent-first workspace that is most of the inbound messages a person would want to hear about.

Not a deliberate exclusion

The in-app surface has never made this distinction. NotificationToasts.tsx fires on any message.new that is not yours and not a system row:

if (e.type !== 'message.new') return
if (m.authorId === meRef.current) return
if (m.kind === 'system') return
…
const author = useParticipants.getState().byId[m.authorId]

byId holds agents, so the desktop toast has always shown agent replies. The two surfaces disagreed, and the one that was never wired is the one that reaches a locked phone.

push.ts's own header points the same way — the soft-disable exists so callers can invoke it freely:

lets the WS bridge call notifyMessage(…) unconditionally

The change

dispatchMessagePush in push.ts, called from both the HTTP route and cmdReply after COMMIT. The HTTP route's behaviour is unchanged — it now calls the extracted function instead of its own copy.

Recipients are unchanged. computeMessageRecipients joins users, so only humans are ever notified, and the mute and "currently looking at the app" filters still apply. Two of the four tests pin exactly that, and they pass with or without the fix — this must not become a broadcast.

Author name now resolves through participants with a users fallback:

SELECT COALESCE(
         (SELECT name FROM participants WHERE id = $1 AND company_id = $2),
         (SELECT display_name FROM users WHERE id = $1)
       ) AS name

Agents have no users row, so the previous users-only lookup would have titled the notification with a raw agent id like a-1f2e3d4c.

Verification

Four integration cases driving the real runCli. Two go red without the dispatch:

not ok 1 - an agent reply reaches the push path
not ok 2 - the notification is titled with the agent name, not its id
# pass 2  # fail 2

The other two are the guards against over-reaching, and pass either way: a human whose status is 'avail' is still skipped, and a muted conversation is still muted.

notifyMessage gains a test-only observation hook. APNs soft-disables without credentials, so the send itself is unobservable in a test and the payload the caller built is the assertion that matters; the hook is three lines and changes no behaviour.

Unit suite 1102 pass / 0 fail. The neighbouring integration suites that exercise the routes I touched stay green (agent-cli-side-effects 5/5, human-cli-collaboration 1/1). tsc --noEmit, biome lint ., all three source guards clean.

Worth a second opinion

This makes phones buzz for agent replies where they previously did not, so it is a real change in what users experience — I believe it is the intended behaviour rather than a new feature, on the evidence above, but it is the kind of call worth disagreeing with me on. Every existing filter is untouched, so the blast radius is exactly "the messages the in-app toast already showed".