Overview
The Gmail integration connects your Claws to your email through Google’s OAuth flow. Once authorized, a Claw can read incoming messages, search your inbox, draft and send replies, apply labels, and manage threads, all from within its isolated ClawCage container. Whether you need to triage a shared support inbox, auto-respond to routine inquiries, or extract data from incoming emails for processing in other tools, your Claw handles it without you touching the inbox.
You choose the access level during setup. Read-only mode lets your Claw monitor and analyze emails without modifying anything. Full access lets it draft, send, label, and organize. The OAuth scopes requested match exactly what you select: a read-only Claw never gets send permissions.
What Your Claw Can Do
Read and search emails. Your Claw can read email content, metadata, headers, and attachments. It can search across your inbox using Gmail’s search operators (by sender, date range, label, subject, or keywords). This enables workflows like finding all invoices from a specific vendor or surfacing unread emails from VIP senders.
Draft and send responses. With full access, your Claw can compose and send emails. Responses are context-aware: the Claw reads the full thread before replying, so it understands the conversation history. Use this for automated support responses, follow-up reminders, or acknowledgment emails.
Manage labels and organization. Claws can apply, remove, and create Gmail labels. Use this for automated triage: incoming emails are categorized by content, sender, or keywords, and the right label is applied. Combined with other integrations, your Claw can label an email and simultaneously create a task in your project management tool.
Handle threads. Gmail’s threading model is fully supported. Your Claw understands which messages belong to the same conversation and can read the full thread context before taking action. Replies are added to the correct thread, not sent as new emails.
Process attachments. Claws can read attachment metadata and content. Incoming invoices, reports, or documents can be parsed and their data routed to spreadsheets, databases, or other tools.
Who Can Reach Your Claw
Gmail whitelisting controls exactly which emails your Claw processes:
- By email address. Whitelist specific senders like
alice@partner.com. Only emails from whitelisted addresses are processed. - By domain. Whitelist entire domains like
@company.com. Every email from that domain reaches the Claw, while external senders are filtered out. - By distribution list. Whitelist a Google Group or distribution list address. Emails sent to the list are processed; direct emails from unlisted senders are not.
This works alongside three Claw scoping levels:
Private Claw. Only the creator interacts with the Claw. It reads your personal inbox, drafts responses for your review, and organizes your email. Nobody else in the organization can access it or see its outputs. Example: a personal inbox assistant that triages your morning email, drafts responses to routine messages, and flags anything that needs your attention.
Team Claw. Whitelisted team members share the Claw. It processes a shared inbox like support@company.com, triaging incoming messages and routing them to the right team member. Only whitelisted team members can configure or query the Claw. Example: a support team Claw that reads support@company.com, categorizes tickets by urgency, drafts initial responses, and creates Jira tickets.
Organization-wide Claw. Any org member can interact. The Claw serves as a company-wide email assistant, so anyone at @company.com can ask it to search for emails, draft responses, or generate email-based reports. Whitelisted to the company domain so external users cannot interact.
Security
- OAuth scope minimization. Read-only mode requests
gmail.readonly. Full access requestsgmail.modifyandgmail.send. No unnecessary scopes are ever requested. - Tokens encrypted at rest. Gmail OAuth tokens are stored with AES-256 encryption and decrypted only inside the ClawCage at runtime.
- ClawCage isolation. Each Claw runs in its own Docker container. Gmail credentials are injected at startup and are inaccessible to other Claws or the host system.
- No email content stored. Emails are processed in-memory within the ClawCage. ClawStaff does not cache or store email content outside the container.
- Automatic token refresh. Google’s token expiry is handled transparently. Your Claw stays connected without re-authorization.
- Audit logging. Every Gmail API call (emails read, sent, labeled) is logged in the ClawStaff dashboard.
- Revoke anytime. Disconnect from the ClawStaff dashboard or revoke access in your Google account settings. Tokens are immediately invalidated.
How It Works
- Connect Gmail. From the ClawStaff dashboard, start a Google Workspace connection and enable Gmail. Choose read-only or full access.
- Authorize with Google. Review the requested OAuth scopes on Google’s consent screen and click Allow.
- Configure your Claw. Set up email triggers, whitelisting rules, and response behavior. Define which emails your Claw should process and what actions it should take.
- Claw manages your inbox. Your Claw receives and processes emails from within its ClawCage container, taking actions based on your configuration. All processing happens in isolation.
Cross-Integration Workflows
Gmail paired with other integrations enables end-to-end email automation:
- Gmail to Jira. A customer emails a bug report. Your Claw reads the email, extracts the issue details, creates a Jira ticket with the right priority and labels, and replies to the customer with the ticket number.
- Gmail to Slack. An important email arrives from a partner. Your Claw posts a summary in the relevant Slack channel so the team sees it immediately without checking email.
- Gmail to Google Sheets. Invoices arrive by email. Your Claw extracts amounts, dates, and vendor names from each invoice and logs them in a Google Sheets tracker automatically.
- GitHub to Gmail. A critical CI pipeline fails. Your Claw composes an email to the team lead with the failure details, affected services, and a link to the GitHub Actions run.