Plugins, connectors & email

Sonderr talks to the outside world through three doors, and only three: plugins (bundles of behavior added to the workspace), connectors (links to the services you already use), and email (send-side, tightly scoped). All three follow the same philosophy as the rest of the product: explicit setup, honest boundaries, secrets that never leak into chat.

1 · The Plugin Hub

Plugins are optional capability packs managed from the Plugin Hub in the workspace. The built-in catalog today includes sites — a pack of website-flavored helpers the agent uses when it’s building or auditing a site — and code-review, the structured review pass that turns “look at my diff” into a findings-first report. Plugins don’t change permissions; they change competence. With a plugin on, the agent has a better procedure for that kind of work; without it, it still works, just with the generic playbook.

Installing a plugin is a toggle, not a download-and-pray: the hub shows what each one adds, and removal is instant. A plugin can never grant access the current task mode and Tools & Access level don’t already allow — it rides within the same gates as every built-in tool.

2 · Connectors

Connectors link Sonderr to services you already use. The built-in roster: Gmail, Notion, Slack, Google Drive, GitHub and Linear. A connector gives the agent scoped surfaces — read a doc, search a board, check a repo’s state — that appear as ordinary tools with proper schemas once the connector is authorized.

Two rules apply across the board. First, authorization is per-connector and visible: you can see what’s linked and revoke it in place. Second, connector actions that mutate anything — posting a Slack message, editing a Notion page, creating a Linear issue — are mutations like any other: they need Build mode, an access level that permits them, and intent in your current message. A stale “post this later” from three conversations ago cannot authorize a post today.

3 · Email that behaves

Email is send-side only — Sonderr composes and sends; it does not read your inbox. Two paths:

• Gmail (OAuth). Authorize with your Google account; Sonderr requests exactly one scope — gmail.send — and nothing else. Client credentials come from SONDERR_GMAIL_CLIENT_ID / SONDERR_GMAIL_CLIENT_SECRET (env or the secret store), sends are rate-limited locally to keep one runaway session from torching your reputation, and revoking the grant in your Google account cuts access instantly.
• SMTP presets. Brevo, Mailgun and SendGrid ship pre-configured (host and port set; you supply the generated username, the verified sender address and an API key stored owner-only). Any standards-compliant SMTP server works too.

Either way the flow is the same: the agent drafts in chat, you see exactly what would go out and to whom, and sending requires a present-turn instruction. Drafts aren’t emails; nothing leaves on a technicality.

4 · Where the secrets live

Connector tokens, SMTP keys and Gmail credentials all land in the local credential store — owner-only file permissions, written through exclusive no-follow temp files, symlink-rejecting paths, backed up before reset instead of silently dropped. The model never sees secret values: references and status, yes; contents, no. If a credential might have been exposed anyway — you pasted it into chat, say — the security docs’ advice applies: rotate it. Secret scrubbing at every shared output boundary exists to make that rare, not to make rotation optional.

5 · Recipes

• Weekly report to your inbox — Build mode + Gmail connector: “summarize this week’s commits from the repo connector and email the summary to me.” Draft appears, you approve, it sends within the local rate limit.
• Notion pipeline mirror — read-only reads from Notion to ground a plan; write-backs only when you explicitly ask for them, one page at a time.
• Diff review with teeth — enable code-review, paste or point at the diff, get the findings-first report with severity and suggested fixes, then decide what the lead applies.