Skip to content

docs: update inbox documentation for always-on behavior (G-08) #8293

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
NgoHarrison merged 1 commit into from
Feb 24, 2026
Merged

docs: update inbox documentation for always-on behavior (G-08) #8293

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions ARCHITECTURE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3939,11 +3939,11 @@ The assistant inbox extends the guardian security model to support controlled cr

The channel inbound handler (`channel-routes.ts`) enforces an access control layer between message receipt and agent processing:

1. When `inbox_enabled` is true and the sender is not the guardian, the handler looks up the sender in `assistant_ingress_members` by `(sourceChannel, externalUserId)`.
2. If no member record exists, the `inbox_default_policy` config determines behavior (allow, deny, or escalate).
3. If a member exists, their individual `policy` field takes precedence.
1. When `senderExternalUserId` is present and the sender is not the guardian, the handler looks up the sender in `assistant_ingress_members` by `(sourceChannel, externalUserId)`.
2. If no member record exists, the message is denied (`not_a_member`).
3. If a member exists, their individual `policy` field determines behavior (allow, deny, or escalate).

Invite tokens are created via the `ingress_invite` IPC contract. Each token is SHA-256 hashed before storage — the raw token is returned exactly once at creation time. External users redeem invites by sending the token as a channel message, which creates a member record with the default policy.
Invite tokens are created via the `ingress_invite` IPC contract. Each token is SHA-256 hashed before storage — the raw token is returned exactly once at creation time. External users redeem invites by sending the token as a channel message, which creates a member record with `allow` policy.

#### Escalation Data Flow

Expand Down
4 changes: 2 additions & 2 deletions assistant/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -292,13 +292,13 @@ The assistant inbox provides secure cross-user messaging, allowing external user

### Ingress Membership

External users join through **invite tokens** — the owner creates an invite via the desktop UI or IPC, and the external user redeems the token by sending it as a channel message. Redemption auto-creates a **member** record with a configurable access policy:
External users join through **invite tokens** — the owner creates an invite via the desktop UI or IPC, and the external user redeems the token by sending it as a channel message. Redemption auto-creates a **member** record with an access policy:

- **`allow`** — Messages are processed normally through the agent pipeline.
- **`deny`** — Messages are rejected with a refusal notice.
- **`escalate`** — Messages are held for guardian (owner) approval before processing.

The default policy for new members is controlled by the `inbox_default_policy` config. Members can be listed, updated, revoked, or blocked via the `ingress_member` IPC contract.
Non-members (senders with no invite redemption) are denied by default. Members can be listed, updated, revoked, or blocked via the `ingress_member` IPC contract.

### Escalation Flow (Dual-Surface)

Expand Down