Skip to content

Account roles: personal, managed, receive-only

Every mail account stores a role and a control scope. Core enforces those values on send. The same checks apply to the macOS app, the primail CLI, and the primail-mcp stdio server. There is no local mail REST listener.

New accounts default to personal and all unless you pass another value at add time.

The default. Read, compose, and send are allowed, subject to control scope.

A stored role you can set and list. Core does not currently stage a confirmation queue or block send for managed. Treat it as a label until a later product change adds extra checks. Do not assume an agent send from a managed account waits for a tap in the app.

Send is blocked on every interface. The error code is send_blocked_receive_only. Typical uses: a no-reply monitoring inbox, or an archive you never want to send from.

The GUI shows a short notice on the account page when the role is receive-only. It does not offer a role picker.

Each account also stores a control scope:

ScopeUI sendCLI / MCP send
all (default)AllowedAllowed
ui_onlyAllowedBlocked (send_blocked_scope)
mcp_onlyBlockedAllowed

Scope is checked on send (and on sender-identity resolve used for send). It does not hide the account from account_list, mailbox_list, or email_get. A ui_only inbox is still readable from MCP.

The GUI shows a notice when scope is not all. It does not offer a scope picker.

Use CLI or MCP. Examples (ids are opaque; substitute your own):

Terminal window
primail account settings-update ACCOUNT_ID --role receive-only
primail account settings-update ACCOUNT_ID --control-scope ui-only

MCP tool: account_settings_update with account_id plus role (personal / managed / receive_only) and/or control_scope (all / mcp_only / ui_only).

Role and scope are local to this device. They do not roam through a Primail cloud account.

See Add more email accounts and Control scopes & safety rails.