Personal Gmail OAuth
Technical: a Google OAuth client authorizes selected Gmail or Calendar scopes such as gmail.send, gmail.modify, gmail.readonly, or calendar.events.
A searchable field manual for Gmail OAuth, Google Workspace agent mailboxes, app passwords, SMTP/IMAP, Cockpit draft approval, email-driven coding agents, built-in model tools, and transactional email providers.
The hard part was not "email." It was choosing the correct identity, permission model, and runtime. These methods solve different problems.
| Method | Best For | Plain English | Main Risk |
|---|---|---|---|
| Personal Gmail OAuth | Personal automations that act as David | The app has permission to use David's Gmail for approved scopes. | Consent, refresh tokens, and scope mistakes. |
| Dedicated Workspace App Password | Named agent mailboxes like jules@agents.dvo88.com | The agent logs into its own mailbox with SMTP/IMAP credentials. | Broad mailbox password and Workspace admin friction. |
| Agent Draft and Cockpit Approval | Human-reviewed outbound agent email | The agent proposes; David approves and sends. | Backend validation and approval UX. |
| Email-Driven Coding Agent | Local command execution triggered by email | An email becomes a work order for a local coding agent. | Highest security risk; must be sandboxed and tested adversarially. |
| Built-In Model Connectors | Quick personal assistant tasks | ChatGPT, Gemini, or Claude uses connected Gmail/Calendar tools. | User-scoped and less portable into custom systems. |
| Transactional Email Provider | Product/system notifications and inbound webhooks | A provider sends and receives application email through APIs. | DNS setup, cost, vendor APIs, and rate limits. |
Use these cards as the practical choosing layer before adding another mailbox or email feature.
Technical: a Google OAuth client authorizes selected Gmail or Calendar scopes such as gmail.send, gmail.modify, gmail.readonly, or calendar.events.
Technical: a real Google Workspace user gets 2-Step Verification and a 16-character App Password for SMTP send and IMAP receive.
Technical: an agent submits a draft through a protected endpoint; the backend creates a review card and sends only after approval.
Technical: a local monitor reads task emails, parses instructions, runs allowlisted commands, edits files inside allowed roots, commits, and replies.
Technical: ChatGPT, Gemini, and Claude expose user-authorized Gmail, Calendar, Drive, Docs, and Workspace-style connectors depending on tier and admin settings.
Technical: providers such as Resend, Postmark, SendGrid, and Amazon SES send application email through APIs or SMTP and can route inbound email to webhooks.
Adding send, receive, archive, label, delete, or another user is mostly an authorization problem. The safest path is to expand one capability at a time and smoke-test the exact action.
| Method | Add Another User or Inbox | Add Delete/Edit Inbox | Additional Steps |
|---|---|---|---|
| Personal Gmail OAuth | Each user must authorize unless Workspace delegation is used. | Use gmail.modify for archive, labels, read state, and trash-style actions. | Update scopes, re-consent, store refreshed secrets, update scope check scripts. |
| Workspace App Password | Create another Workspace user, activate 2FA, generate an App Password. | IMAP can move/delete folders; Gmail labels/settings need Gmail API. | Add mailbox registry entry, GCP secret, SMTP/IMAP smoke tests. |
| Agent Draft Approval | Add mailbox config, allowlist, secret, and full-address validation. | Add explicit actions and keep destructive actions approval-gated first. | Add propose, approve, reject, send, archive, and delete audit logs. |
| Email-Driven Coding Agent | Add sender policy and mailbox routing. | Possible but dangerous; limit to post-success cleanup at first. | Write failing security tests before expanding command or inbox actions. |
| Built-In Connectors | Depends on account, product tier, and admin policy. | Depends on connector capability and user confirmation flow. | Enable connector, grant access, confirm policy, test with a real prompt. |
| Transactional Provider | Add aliases, domains, routes, or inbound addresses. | Does not edit Gmail inboxes; it manages provider queues/webhooks. | Verify DNS, create API key, configure webhook, set rate limits. |
Pick the identity and control model first, then choose the implementation.
These are not Gmail replacements. They are product email systems with APIs, SMTP relay, domain verification, inbound webhooks, analytics, templates, and rate limits.
| Provider | Strong At | Authorization | Cost Shape |
|---|---|---|---|
| Resend | Developer-friendly API, React-style templates, sending and receiving. | Domain DNS verification plus API key and optional webhook secret. | Free limited tier; paid plans start around $20/month for higher volume. |
| Postmark | Transactional deliverability, inbound processing, message streams. | Domain verification, server token, inbound webhook configuration. | Small free allowance; paid plans start around $15/month for 10k emails. |
| SendGrid | High-volume email API, templates, marketing add-ons. | Domain authentication, API key, sender identity, webhook signing. | Free plan changed after May 2025; Essentials commonly starts around $19.95/month. |
| Amazon SES | Low-cost AWS-native sending and inbound processing. | Domain identity, IAM permissions, production access, SNS/S3/Lambda routing. | Usage-priced, roughly cents per thousand emails plus data and inbound charges. |
Every future mailbox or email provider key should be recorded with these fields.
These are the defaults unless a project has a reason to override them.
| Rule | Reason |
|---|---|
| Use personal Gmail OAuth sparingly | It should mean "this app can act as David," not "we needed any email sender." |
| Use dedicated Workspace mailboxes for named agents | Hermes, CTO, Jules, and similar systems need separate identities and secrets. |
| Use Cockpit approval for important outbound messages | The agent can draft while David keeps final authority. |
| Use transactional providers for product email | They are built for delivery, templates, webhooks, analytics, and rate limits. |
| Smoke-test the actual capability | A token check is not the same as proving send, read, modify, archive, delete, or approve. |
Source details are summarized in the canonical markdown file. This page intentionally excludes secrets and private operational details.
No matching sections. Try a broader term like Gmail, agent, inbox, provider, OAuth, or app password.