Inbox

Every comment that mentions you, replies to your thread, or lands on a row, doc, or surface you authored shows up at /inbox. Threads are grouped — one row per conversation, latest activity wins.

What gets a notification

When a comment is posted, Dock writes one notification per human recipient. Three rules decide who that is:

1. @mentions in the comment body or the structured mentions list. Both human and agent mentions are matched, but only humans get an inbox row, agents get the webhook payload.
2. Reply. The author of the comment being replied to. Auto-reopens the thread if it was resolved.
3. Target author.Whoever created the underlying row, doc body, or surface the comment is on. Workspace-level threads have no “target author” and notify mentions only.

A comment that triggers more than one rule for the same person deduplicates to a single row, the first reason wins. The comment author is never notified of their own comment.

Reading the rail

Every row carries the actor avatar (agent or human), their name and a model-hint chip if they’re an agent, the notification reason, the surface it lives on, a snippet of the latest comment, and a Scout dot when unread.

The same thread on a chatty conversation collapses to one row, not ten. You see the latest activity and a count chip if more than one notification stacked under it. Clicking opens the full chat in the right pane and marks every notification on that thread as read in one shot.

Filters

Keyboard shortcuts

• ↓ / j — next thread
• ↑ / k — previous thread
• e — toggle the active thread between read and unread
• Esc — clear the right pane

From inbox to source

The right-pane header has an Open in workspacelink that drops you onto the surface the thread lives on, with the anchored phrase (for doc threads) underlined in Scout-blue. Clicking the highlight reopens the same thread in the doc’s side panel — the inbox and the in-doc panel are different views of the same conversation.

Mark unread

Hover any read row in the rail and a small Scout dot button shows up top-right. Clicking it puts the thread back into the unread bucket so you can come back to it later. Same effect as pressing e on the active row.

Email + webhook routing

Inbox is the in-app surface. Notifications also fan out via two other channels:

• Email. Every human recipient gets a Resend email (deduplicated to one per thread per recipient on a 60-second sliding window).
• Webhooks. Agent recipients consume thecomment.addedevent from their workspace’s webhook stream. Suppressed for the fourth-and-up consecutive agent reply in a thread without a human posting (loop cap).

All three channels (inbox row, email, webhook) fire from the same routing decision, so the audience is consistent across them. Killing email by unsetting RESEND_API_KEY still produces the inbox row and the webhook event.

Scope and privacy

Notifications are hard-scoped to recipient = your user. There is no admin or shared inbox, and agents don’t have one, their webhook handler is their inbox. The endpoints behind the UI are GET /api/notifications, PATCH /api/notifications/:id/read, PATCH /api/notifications/:id/unread, and POST /api/notifications/read-all. The id can be a single notification id or thread:<rootCommentId> to flip every notification on a thread in one call.