Forem: Qasim Muhammad

Manage Nylas Applications, Connectors, and Grants from the CLI

Qasim Muhammad — Mon, 11 May 2026 02:09:02 +0000

The nylas admin commands let you manage your Nylas infrastructure without the web dashboard. Create applications, configure provider connectors, manage OAuth credentials, and monitor grants — all from the terminal.

What nylas admin does

Full API management surface: applications, callback URIs, provider connectors (Google, Microsoft, IMAP), credentials, and grants. Useful for CI/CD pipelines, multi-tenant setups, and infrastructure-as-code workflows.

Quick Start

brew install nylas/nylas-cli/nylas
nylas init
nylas admin applications list

Key commands

Command	What it does
`nylas admin applications list`	List all applications
`nylas admin applications create`	Create a new application
`nylas admin connectors list`	List provider connectors
`nylas admin connectors create`	Create a Google/Microsoft/IMAP connector
`nylas admin credentials list <connector-id>`	List credentials for a connector
`nylas admin credentials create`	Add OAuth credentials
`nylas admin callback-uris list`	List OAuth callback URIs
`nylas admin callback-uris create --url <url>`	Register a new callback URI
`nylas admin grants list`	List all grants on the application
`nylas admin grants stats`	Show grant statistics

Creating an application and connector

# Create app
nylas admin applications create --name "prod-email" --json

# Add Google connector
nylas admin connectors create \
  --provider google \
  --client-id $GOOGLE_CLIENT_ID \
  --client-secret $GOOGLE_CLIENT_SECRET

# Register callback URI
nylas admin callback-uris create --url https://myapp.com/oauth/callback

Monitoring grants

# How many users are connected?
nylas admin grants stats --json

# List all grants with their status
nylas admin grants list --json | jq '.[] | {id, provider, status}'

All commands: Nylas CLI Command Reference

Get started: brew install nylas/nylas-cli/nylas — other install methods

Agent Policies and Rules — Control What Your AI Agent Can Send and Receive

Qasim Muhammad — Mon, 11 May 2026 02:08:56 +0000

The nylas agent policy and nylas agent rule commands define guardrails for AI agent email accounts. Set who the agent can email, what triggers are allowed, and what actions to take on inbound messages — all enforced server-side.

What policies and rules do

A policy is a named container for rules. Rules define conditions and actions: "if the sender is external, block" or "if sending to a non-internal domain, require approval." These fire before the agent sees the message, so prompt injection can't bypass them.

Quick Start

nylas agent policy create --name "production-guardrails" --json
nylas agent rule create \
  --name "internal-only-outbound" \
  --condition "recipient_domain != company.com" \
  --action block

Key commands

Command	What it does
`nylas agent policy list`	List all policies
`nylas agent policy create --name N`	Create a named policy
`nylas agent policy get <id>`	Show policy details
`nylas agent policy delete <id> --yes`	Delete a policy
`nylas agent rule list`	List all rules
`nylas agent rule create --name N --condition C --action A`	Create a rule from flags
`nylas agent rule create --data-file rule.json`	Create from JSON file
`nylas agent rule get <id>`	Show a rule
`nylas agent rule delete <id> --yes`	Delete a rule
`nylas agent account create <email> --policy-id <id>`	Attach policy to agent

Example: restrict outbound to internal domains only

# Create policy
POLICY=$(nylas agent policy create --name "internal-only" --json | jq -r '.id')

# Add rule: block any outbound to non-company domains
nylas agent rule create \
  --policy-id $POLICY \
  --name "block-external-send" \
  --condition "direction == outbound AND recipient_domain != mycompany.com" \
  --action block

# Attach to agent account
nylas agent account create agent@mycompany.nylas.email --policy-id $POLICY

Example: auto-archive marketing emails

nylas agent rule create \
  --name "archive-marketing" \
  --condition "sender_domain IN (marketing.example.com, promo.example.com)" \
  --action archive

All commands: Nylas CLI Command Reference

Get started: brew install nylas/nylas-cli/nylas — other install methods

Manage Email Signatures from the CLI — Create, List, and Attach to Sends

Qasim Muhammad — Mon, 11 May 2026 02:08:52 +0000

The nylas email signatures commands manage reusable email signatures stored per-grant. Create HTML signatures once, attach them to any send with a flag — no more pasting footers manually.

What email signatures do

Signatures are HTML blocks stored server-side and attached to outgoing emails via --signature-id. Create different signatures for different contexts (formal, casual, department) and switch between them per-send.

Quick Start

nylas email signatures create --name "Work" --body "<p>— Qasim<br>Staff SRE, Nylas</p>"
nylas email send --to alice@example.com --subject "Hello" --body "..." --signature-id SIG_ID

Key commands

Command	What it does
`nylas email signatures list`	List stored signatures
`nylas email signatures show <id>`	Show signature HTML
`nylas email signatures create --name N --body B`	Create from inline HTML
`nylas email signatures create --name N --body-file FILE`	Create from HTML file
`nylas email signatures update <id>`	Update a signature
`nylas email signatures delete <id> --yes`	Delete a signature

Creating a signature from a file

cat > sig.html << 'EOF'
<p style="font-family: sans-serif; font-size: 14px;">
  <strong>Qasim Muhammad</strong><br>
  Staff SRE · Nylas<br>
  <a href="https://cli.nylas.com">cli.nylas.com</a>
</p>
EOF

nylas email signatures create --name "Default" --body-file sig.html --json

Using a signature when sending

nylas email send \
  --to team@company.com \
  --subject "Weekly update" \
  --body "Here's the summary..." \
  --signature-id <sig-id>

The signature HTML is appended to the email body automatically.

All commands: Nylas CLI Command Reference

Get started: brew install nylas/nylas-cli/nylas — other install methods

Hosted Email Templates — Create, Render, and Send with Variable Substitution

Qasim Muhammad — Mon, 11 May 2026 02:08:47 +0000

The nylas template commands manage hosted email templates with variable substitution. Define a template once, render it with dynamic data, and send — no local files needed.

What hosted templates do

Templates are stored in Nylas and rendered server-side. Use {{variable}} placeholders for dynamic content (names, dates, URLs). Templates support HTML and plain text, with Mustache-style variable interpolation.

Quick Start

nylas template create \
  --name "welcome" \
  --subject "Welcome, {{name}}!" \
  --body "<h1>Hey {{name}}</h1><p>Your account is ready.</p>"

nylas email send \
  --to new-user@example.com \
  --template-id TPL_ID \
  --template-data '{"name": "Alice"}'

Key commands

Command	What it does
`nylas template list`	List hosted templates
`nylas template create --name N --subject S --body B`	Create a template
`nylas template show <id>`	Show template details
`nylas template update <id>`	Update a template
`nylas template delete <id> --yes`	Delete a template
`nylas template render <id> --data '{}'`	Preview rendered output
`nylas template render-html --body H --engine mustache --data '{}'`	Render inline HTML

Rendering a preview before sending

nylas template render <template-id> \
  --data '{"name": "Bob", "company": "Acme", "link": "https://example.com/onboard"}'

Outputs the fully-rendered HTML so you can verify before sending.

Sending with a template

nylas email send \
  --to customer@example.com \
  --template-id <id> \
  --template-data '{"name": "Alice", "invoice_url": "https://..."}'

The subject line and body variables are both interpolated from the data JSON.

Local templates vs hosted templates

Feature	Local (`nylas email templates`)	Hosted (`nylas template`)
Storage	On-disk files	Nylas API (cloud)
Sharing	Per-machine	Per-application (all users)
Variables	`{{var}}` in file	`{{var}}` via API
Best for	Personal scripts	Team/product emails

All commands: Nylas CLI Command Reference

Get started: brew install nylas/nylas-cli/nylas — other install methods

Manage Booking Pages and Appointments from the Terminal

Qasim Muhammad — Sun, 10 May 2026 16:48:29 +0000

The nylas scheduler\ commands manage booking pages, configurations, and appointments without touching a web dashboard. Create scheduling links, confirm bookings, handle reschedules — all from the terminal.

What nylas scheduler does

Manages the full booking lifecycle: create scheduling pages with availability rules, accept bookings, confirm or cancel them, and track sessions. Replaces Calendly-style web UIs for developers who prefer CLI workflows.

Quick Start

\bash brew install nylas/nylas-cli/nylas nylas init nylas scheduler pages list \\

Key commands

Command	What it does
`nylas scheduler pages list\`	List scheduling pages
`nylas scheduler pages create\`	Create a new booking page
`nylas scheduler pages show <id>\`	View page details
`nylas scheduler bookings list\`	List all bookings
`nylas scheduler bookings confirm <id>\`	Confirm a pending booking
`nylas scheduler bookings reschedule <id>\`	Reschedule a booking
`nylas scheduler bookings cancel <id>\`	Cancel a booking
`nylas scheduler configurations list\`	List scheduling configurations
`nylas scheduler configurations create\`	Create availability rules

Creating a booking page

\bash nylas scheduler pages create \\ --name "30-min intro call" \\ --duration 30 \\ --json \\

Returns a booking URL you can share. The page respects your calendar availability automatically.

Confirming a booking

\bash nylas scheduler bookings list --status pending --json nylas scheduler bookings confirm <booking-id> \\

Rescheduling

\bash nylas scheduler bookings reschedule <booking-id> \\ --start "2026-05-15T10:00:00-05:00" \\ --end "2026-05-15T10:30:00-05:00" \\

All commands: Nylas CLI Command Reference

Get started: brew install nylas/nylas-cli/nylas\ — other install methods

Extract OTP Codes from Email in One Command — No Inbox Browsing

Qasim Muhammad — Sun, 10 May 2026 16:47:54 +0000

The nylas otp commands extract one-time passwords from your email automatically. Stop switching to your inbox to copy 6-digit codes — the CLI finds them and copies to your clipboard in under 3 seconds.

What nylas otp does

Scans recent emails for verification codes (6-digit, 8-digit, alphanumeric), extracts them using pattern matching, and copies the latest to your clipboard. Works with Gmail, Outlook, Yahoo, and any IMAP provider.

Quick Start

brew install nylas/nylas-cli/nylas
nylas init
nylas otp get

That's it — the latest OTP code is now in your clipboard. Paste it into the verification form.

Key commands

Command	What it does
`nylas otp get`	Get latest OTP, copy to clipboard
`nylas otp get --raw`	Output only the code (for scripting)
`nylas otp watch`	Watch for new codes in real-time
`nylas otp watch --interval 5`	Poll every 5 seconds
`nylas otp list`	List configured accounts
`nylas otp messages`	Show recent messages with OTP detection

Use in Playwright/Cypress tests

# In your E2E test script:
OTP=$(nylas otp get --raw)
# Use $OTP to fill the verification form programmatically

This eliminates the need for Gmail API credentials in CI/CD pipelines. The CLI handles auth — your test just calls nylas otp get --raw.

Watching for codes in real-time

nylas otp watch --interval 3

Polls every 3 seconds and prints new codes as they arrive. Useful when you triggered a "send verification code" flow and are waiting for delivery.

Common issues

No OTP found
The code might not have arrived yet. Use nylas otp watch to wait, or check nylas otp messages to see what emails were scanned.

Wrong code extracted
If multiple verification emails arrived recently, nylas otp get returns the newest. Use nylas otp messages to see all candidates.

All commands: Nylas CLI Command Reference

Get started: brew install nylas/nylas-cli/nylas — other install methods

Record and Transcribe Zoom, Meet, and Teams Meetings from the CLI

Qasim Muhammad — Sun, 10 May 2026 16:47:52 +0000

The Nylas Notetaker is an AI bot that joins your video meetings, records audio/video, and produces a transcript. You control it from the terminal — no browser dashboard needed.

What nylas notetaker does

The notetaker bot joins Zoom, Google Meet, or Microsoft Teams calls on your behalf. It records the meeting, generates a transcript, and stores both as downloadable media. One command to start, one to retrieve the output.

Supports 3 platforms (Zoom, Meet, Teams), produces transcripts in under 5 minutes post-meeting, and stores recordings for 7 days by default.

Quick Start

brew install nylas/nylas-cli/nylas
nylas init
nylas notetaker create --meeting-link https://zoom.us/j/123456

Key commands

Command	What it does
`nylas notetaker list`	List all notetakers
`nylas notetaker create --meeting-link URL`	Send a bot to record a meeting
`nylas notetaker create --meeting-link URL --join-time "tomorrow 2pm"`	Schedule a future recording
`nylas notetaker show <id>`	Check recording status
`nylas notetaker media <id>`	Get recording + transcript URLs
`nylas notetaker delete <id>`	Cancel or remove a notetaker

Scheduling a recording for tomorrow

nylas notetaker create \
  --meeting-link "https://meet.google.com/abc-defg-hij" \
  --join-time "2026-05-12T14:00:00-05:00"

The bot joins at the specified time. No manual intervention needed. If the meeting hasn't started, the bot waits up to 10 minutes before timing out.

Retrieving the transcript

nylas notetaker media <notetaker-id> --json

Returns URLs for the video recording and text transcript. Pipe to jq for automation:

nylas notetaker media <id> --json | jq '.transcript_url'

Common issues

Bot doesn't join the meeting
Check that the meeting link is a valid Zoom, Meet, or Teams URL. The bot requires the meeting to be in progress or starting within 10 minutes of the join time.

Transcript is empty
The meeting may have been too short (under 30 seconds) or the audio quality was too low for transcription.

All commands: Nylas CLI Command Reference

Get started: brew install nylas/nylas-cli/nylas — other install methods

5 Nylas CLI commands every AI agent should have access to

Qasim Muhammad — Mon, 04 May 2026 21:11:14 +0000

Adding email and calendar tools to an AI agent is mostly an exercise in restraint. Give it 50 commands and the agent gets confused. Give it 5 carefully-chosen ones and it punches above its weight.

After running agents against the Nylas CLI for a few months, these are the five I keep coming back to. Each gets exposed via MCP (nylas mcp install) so the agent can call them directly.

1. `nylas email send`

The most-used tool by a wide margin.

nylas email send \
  --to alice@example.com \
  --subject "Re: budget review" \
  --body "Approved. See you Friday."

Why it ranks first: every agent task that touches the outside world eventually needs to communicate the result. A pull request shipped, an order placed, a bug filed — someone wants to know. Email is the lowest-common-denominator channel.

Agent prompt pattern that works:

When you complete a task that affects another person, send them an email summary. Use nylas email send with their address from the ticket. Subject line should match the ticket title. Body should be 2-3 sentences max.

2. `nylas email list` `--json`

Reading is half of email. The --json flag matters: agents parse JSON, not prose tables.

nylas email list --unread --limit 20 --json | jq '.[] | {from: .from[0].email, subject, snippet}'

Filters that matter most:

--unread — only what is new
--from "alice@example.com" — scope to a sender
--query "invoice" — text search across subject + body
--in folder/Inbox — provider-specific folders

A common pattern: every 5 minutes, the agent runs nylas email list --unread --json, sees 0-5 new messages, and decides whether each needs human attention.

3. `nylas calendar events list`

Most "schedule a meeting" requests fail because the agent does not know what is already on the calendar. Give it visibility.

nylas calendar events list \
  --start "2026-05-04T00:00:00Z" \
  --end "2026-05-11T00:00:00Z" \
  --json

This returns a week of events as JSON the agent can reason over. Pair with nylas calendar find-time for "find a 30-minute slot when alice@ and bob@ are both free":

nylas calendar find-time \
  --participants alice@example.com,bob@example.com \
  --duration 30 \
  --window-start "2026-05-04T09:00:00-05:00" \
  --window-end "2026-05-08T17:00:00-05:00"

4. `nylas contacts search`

This one surprised me. The agent constantly needs the answer to "what is the email of the person whose name is X". Without contacts access, it asks the user. With contacts access, it just looks up.

nylas contacts search --query "alice" --json

Returns matches against name, email, and company. Three-letter queries work; the search is fuzzy.

A specific pattern that pays off: when the agent drafts an email, it can run a contacts lookup on every name mentioned in the body to verify it has the right email. "Email Alice about the launch" without a contacts tool means asking which Alice. With the tool, the agent disambiguates by company or role.

5. `nylas agent account create`

For tasks that involve a new identity (testing flows, signing up for services, isolating per-PR test inboxes), the agent should be able to provision its own.

nylas agent account create test-$(uuidgen)@yourapp.nylas.email --json

Pair with nylas agent account delete to keep things tidy:

nylas agent account delete $GRANT_ID --yes

This is the meta-tool. The agent can spawn one-shot inboxes for E2E tests, signup automation, or cross-account verification. Most other "AI agents and email" stacks miss this primitive.

What I deliberately left off

Five more commands that are great but did not make the cut for a default agent install:

Command	Why excluded
`nylas email mark-starred`	Personal preference; agent has no opinion about importance
`nylas email delete`	Destructive; require human confirmation by default
`nylas calendar events create`	Powerful but easy to misuse — most teams want a human in the loop
`nylas webhook create`	Better as a one-time setup by the operator, not an agent action
`nylas agent rule create`	Same — policy and rules are operator-level config

A safer agent surface is a smaller surface. Add commands as the agent earns trust.

How to install just these five

When the MCP install gives you the full tool set and you want to scope it down:

// In your AI tool's MCP config, after running `nylas mcp install`
{
  "mcpServers": {
    "nylas": {
      "command": "nylas",
      "args": ["mcp", "serve"],
      "env": {
        "NYLAS_MCP_TOOLS": "email_send,email_list,calendar_events_list,contacts_search,agent_account_create"
      }
    }
  }
}

The NYLAS_MCP_TOOLS env var allow-lists which tools the server exposes. Everything else stays hidden from the agent.

The takeaway

The single biggest mistake I see in agent installs: throwing every available tool at the agent and hoping it picks. Better to start with five well-chosen ones and add more as the workflow demands. Send, list, calendar, contacts, agent-account — the five that cover 90% of real agent tasks involving email.

Next steps

Give your AI coding agent an email address — full MCP install for Claude Code, Cursor, Codex
AI agent email MCP — MCP-specific setup walkthrough
Build an LLM agent with email and calendar tools — broader pattern reference
Full command reference

Command deep-dives for the five above:

nylas email send reference — flags, scheduling, GPG, tracking
nylas email list reference — filters, JSON output, pagination
nylas calendar events list reference — date ranges, timezone handling
nylas contacts search reference — fuzzy matching, JSON output
nylas agent account create reference — managed identities, policies

Send email from any Linux server in 60 seconds — no SMTP config

Qasim Muhammad — Mon, 04 May 2026 21:11:05 +0000

You ssh'd into a fresh Linux box and you need to send an email. Maybe a backup completed. Maybe a deploy succeeded. Maybe a process crashed and you want a stack trace in your inbox.

The traditional path: install Postfix, edit main.cf, configure a smart relay, generate SASL credentials, restart the daemon, and pray nothing else on the box uses port 25. That is the 30-minute path.

The 60-second path:

curl -fsSL https://cli.nylas.com/install.sh | bash
~/.config/nylas/bin/nylas auth config --api-key YOUR_KEY
~/.config/nylas/bin/nylas email send --to you@example.com --subject hi --body "From $(hostname)"

Three lines. Zero daemon. Works on every modern Linux distro and macOS.

Why the old path is so slow

Setting up outbound SMTP from scratch involves five separate concerns:

Concern	Time	Failure mode
Install Postfix or Exim	2 min	Distro package conflicts
Configure relayhost	5 min	Wrong port, blocked by ISP, DNS lookup
SASL auth to relay	10 min	Hashing format, postmap regen
TLS to relay	5 min	Cert path, CA bundle
Test send through queue	5 min	mqueue stuck, tail `/var/log/mail.log`

Five places to get it wrong. Most people get it wrong twice before it works.

What the 60-second path skips

The CLI ships a static binary. No package dependencies, no system services, no firewall punches. The send happens over HTTPS to the Nylas API on port 443 — already open in 99% of environments.

Specifically, you are not:

Opening port 25 outbound (most cloud providers block this)
Setting up STARTTLS to a relay
Maintaining sender DKIM/SPF/DMARC keys (the API handles signing)
Writing config files in /etc/postfix

Real-world recipes

Cron job that emails on failure

#!/usr/bin/env bash
if /usr/local/bin/run-backup.sh; then
  exit 0
fi

nylas email send --to oncall@yourcompany.com \
  --subject "[FAIL] backup on $(hostname)" \
  --body "$(date): backup failed. See /var/log/backup.log"

systemd OnFailure handler

# /etc/systemd/system/notify-failure@.service
[Unit]
Description=Notify on service failure for %i

[Service]
Type=oneshot
ExecStart=/usr/local/bin/nylas email send --to oncall@yourcompany.com \
  --subject "[%H] %i failed" \
  --body "Check journalctl -u %i for details"

# In any service that should notify on failure:
[Unit]
OnFailure=notify-failure@%n.service

This is exactly the pattern the systemd man pages document for OnFailure, with one less moving part.

Deploy notification from CI

nylas email send --to team@yourcompany.com \
  --subject "✅ Deploy v${VERSION} to prod" \
  --body "https://app.example.com/deploys/${DEPLOY_ID}"

Shell trap on script exit

trap 'nylas email send --to me@example.com --subject "rebuild done on $(hostname)" --body "exit code $?"' EXIT

./long-running-rebuild.sh

What about `mailx`, `msmtp`, `sendmail`?

They are venerable, and on a single machine where you already have a working relay, they are fine. Where they hurt:

mailx needs an MTA underneath (Postfix, Exim). Nothing changes about the SMTP setup.
msmtp is itself an SMTP client, so you still maintain relay credentials and TLS.
sendmail is the historical command, usually backed by Postfix.

The Nylas CLI replaces all three for the "I need to send from a script" use case. There is no relay to maintain because the relay is the API.

The 60-second checklist

# 1. Install
curl -fsSL https://cli.nylas.com/install.sh | bash

# 2. Add to PATH for the session
export PATH="$HOME/.config/nylas/bin:$PATH"

# 3. Auth
nylas auth config --api-key YOUR_KEY

# 4. Test
nylas email send --to you@example.com --subject hi --body "from $(hostname)"

# 5. Verify it landed (should be in your inbox in <30 sec)

If step 5 worked, you are done. Add the binary location to a system-wide PATH (e.g., symlink to /usr/local/bin) if other users on the box need it.

A note for hardened environments

If your server has no outbound HTTPS — air-gapped, restricted egress firewall — the CLI cannot reach the API. In that case, ship messages to an internal queue (or a relay box that does have egress) and let that machine call the CLI. The CLI itself is not the bottleneck; outbound HTTPS is.

Otherwise, this is the cleanest "make this Linux box send mail" setup I have used.

Next steps

Send email from the terminal — full nylas email send reference
Best CLI email tools compared — head-to-head with mutt, mailx, msmtp
PowerShell email reports — same idea on Windows
Full command reference

Command references used in this guide:

From Gmail OAuth hell to one-line agent identity

Qasim Muhammad — Mon, 04 May 2026 21:10:57 +0000

I tried to give an AI agent its own email account three different ways. The first two took most of an afternoon. The third took 28 seconds. This is the migration story.

Attempt 1: dedicated Gmail account

The first instinct: just create a Gmail. Free, familiar, works everywhere.

Forty-five minutes in:

Created a new Google account with a phone number Google would accept (the agent does not have a phone)
Configured 2FA, generated an app password (Gmail no longer accepts plain passwords for IMAP)
Hit the "less secure apps" wall, learned it has been retired
Set up OAuth 2.0 client in Google Cloud Console
Configured the consent screen, reviewed scopes, marked it "Internal"
Realised Internal apps cannot be created on free Workspace, so I made it External
Filled in the privacy policy URL, terms URL, app domain — for an agent

I had not sent a single message yet.

Attempt 2: shared Gmail with a +alias

"Just use me+agent@gmail.com" is the popular shortcut. It works for receiving (Gmail routes + aliases to the same inbox), but:

The "From" address on outbound is still the parent account
The agent's mail mixes with mine, so my filters break
Compromise of the agent's credentials = compromise of my personal mail
Audit logs cannot tell us apart

Two hours later I gave up on this path. The mixing problem is fatal once you have more than one agent.

Attempt 3: `nylas agent account create`

$ nylas agent account create coder@yourapp.nylas.email

✓ Agent account created successfully!

  Email:      coder@yourapp.nylas.email
  Provider:   nylas
  Status:     valid

Twenty-eight seconds wall-clock. No OAuth, no Workspace seat, no shared mailbox.

What is happening under the hood

Three things, in this order:

The CLI auto-creates the nylas connector on your application if it does not exist. This is a one-time, idempotent setup.
It provisions a managed mailbox under your application's *.nylas.email zone. The mailbox lives entirely on Nylas — no Gmail, no Workspace, no third-party IMAP.
It stores the new grant locally so subsequent CLI commands resolve it without an explicit --grant.

The grant is provider=nylas, which means: no OAuth handshake, no token refresh, no client-secret rotation. The identity is managed end-to-end.

Side-by-side comparison

Step	Gmail OAuth	Agent account
Create the identity	~5 min (account, 2FA, app password)	One command
Configure OAuth client	~12 min (Cloud Console, scopes, consent)	Not applicable
Wire up auth in your app	~10 min (refresh token plumbing)	One `nylas auth config`
Setup time total	~45 min	~30 sec
Per-month cost	Workspace seat $6	None
Token refresh	Yours to manage	Not applicable
Multi-provider reach	Gmail only	Gmail, Outlook, Exchange, Yahoo, iCloud, IMAP, agent

Migrating an existing agent

If you have already wired up an agent to a Gmail account, the migration is mechanical:

# 1. Provision the agent's new identity
nylas agent account create coder@yourapp.nylas.email

# 2. Optional: enable IMAP/SMTP (if your agent uses a stock library)
nylas agent account update coder@yourapp.nylas.email \
  --app-password 'ValidAgentPass123ABC!'

# 3. Send a test
nylas email send --to you@example.com \
  --subject "test from new agent identity" \
  --body "Hi from the managed inbox."

# 4. Update the agent's prompt / config to use the new address

That is the whole migration. The hardest part is finding everywhere the old address is hard-coded.

What I'd warn future-me about

Three lessons from the misadventure:

Phone number requirement: Gmail's signup will demand a phone for verification. Agents do not have phones. Burn an OTP-friendly number and accept Google may flag the account later.
OAuth refresh tokens expire: a Gmail OAuth refresh token is not infinite. Tokens for unverified Cloud apps expire after 7 days; production verification is its own multi-week project.
Per-seat costs scale: if your team runs 5 agents, that is 5 Workspace seats at $6 each = $30/mo just to give them mail.

When Gmail still wins

Be honest about the trade. If the agent must read or send from an existing inbox at @yourcompany.com (your real domain), and your company is on Workspace, you do not want a separate Nylas address. In that case, OAuth Gmail and pay the setup cost. The agent identity model is for new agent inboxes, not for migrating your CEO's mailbox.

For everything else — testing, signup automation, agent-to-agent messaging, ephemeral inboxes, managed bots — the agent account wins on every dimension I can measure.

Next steps

Create an AI agent email identity — the full setup walkthrough
Why AI agents need email — the case before the setup
Email as identity for AI agents — the deeper argument about agent identity
Full command reference

Command references used in this guide:

AI agents need email — your MCP setup is incomplete without it

Qasim Muhammad — Mon, 04 May 2026 21:10:49 +0000

Your MCP setup probably has filesystem, Slack, GitHub, maybe a database connector. Common stack. Common gap: no email.

That gap is more important than most teams realise. Here is the case for fixing it.

The world the agent lives in

Imagine the agent's day from its perspective. It opens a ticket. The ticket references a customer. The customer's prior emails are in your inbox. The fix the agent ships triggers a notification email to that customer. A reply lands a few hours later. Without an inbox, the agent only sees the ticket — which is half the conversation.

Email is the universal envelope. Slack and GitHub are walled gardens. Email crosses every boundary your agent's work eventually crosses: customers, partners, vendors, regulators, internal teams that are not on Slack.

The four flows MCP-without-email cannot handle

Flow	What goes wrong
Account verification	Service emails an OTP, agent has no inbox, signup stalls
Customer context	Past correspondence with the customer is in email, agent operates blind
Async hand-off	Agent emails a vendor, vendor replies a day later, agent never sees it
Compliance evidence	Audit asks "what did the agent communicate", email is the record

I hit the first one trying to give Cursor a Stripe API key. Stripe sent a confirmation email, Cursor had no way to read it, signup hung.

What "agent has email" actually means

Three capabilities, in order of value:

Read the inbox — list, search, get message bodies, parse attachments
Send mail — transactional sends from a real address
React in real time — subscribe to inbound events and run a handler

A complete MCP setup gives the agent all three. The Nylas MCP server, installed via nylas mcp install, exposes them as tools the agent can call.

The setup, end-to-end

# Install the CLI
brew install nylas/nylas-cli/nylas

# Auth with API key (no OAuth flow for the install)
nylas auth config --api-key YOUR_KEY

# Provision a managed inbox the agent owns
nylas agent account create coder@yourapp.nylas.email

# Install the MCP server config into Claude Desktop / Cursor / Codex
nylas mcp install

The last command writes the right mcp.servers block into the AI tool's config. Restart the tool and the agent has nylas-email, nylas-calendar, nylas-contacts available as MCP tools.

What changes for the agent

After install, the agent can do things like:

You: Find the last 3 emails from acme-corp@customer.com and summarise their concerns.

Agent: [calls nylas-email tool: list with filter from=acme-corp@customer.com limit=3]
[reads bodies]
Three messages from Jamie at Acme over the past week:
1. Apr 28 — initial bug report about CSV export missing rows
2. Apr 30 — follow-up after our reply, requesting RCA
3. May 2 — escalation noting it is now blocking their finance close
The thread is unresolved. Suggest replying with...

That conversation is impossible without inbox access.

The MCP-purist objection

"MCP is supposed to be small composable tools. Email is too big."

The Nylas MCP server is composable: each method is its own tool — list, get, send, mark_read, mark_starred, search, attachments_list. The agent does not get a giant "do email things" black box. It gets ~12 small tools that compose like the filesystem ones.

Security without ceremony

Three controls keep the agent honest:

Scoped grant: the agent uses an agent-account grant (provider=nylas), separate from your personal Gmail. Compromise of the agent inbox does not touch your personal mail.
Outbound rules: nylas agent rule create --trigger outbound lets you cap who the agent can send to (e.g., only internal domains until you trust it).
Audit log: nylas audit logs enable records every CLI invocation with timestamp, command, and exit code. nylas audit export produces JSON or CSV for compliance.

The audit trail in particular is a feature most MCP setups skip. When the agent sends mail on your behalf, you want a record.

Why not Gmail MCP

There are MCP servers that wrap Gmail directly. They work. Three reasons I prefer the agent-account model:

Identity separation — the agent has its own address, not yours. Replies stay attributable.
Multi-provider — the same agent can read a Gmail inbox, an Outlook inbox, and an IMAP inbox without switching tools.
No OAuth churn — provider=nylas agent accounts skip the OAuth refresh dance.

If you only ever touch Gmail and you are happy with the agent posting from your personal account, a Gmail MCP server is fine. If you want the agent to be an entity in its own right, give it its own inbox.

What to install today

Install the Nylas CLI
Provision an agent account (one command)
Run nylas mcp install
Restart your AI tool
Watch the agent stop asking you to copy-paste verification links

That is the smallest possible upgrade with the largest workflow shift. If you skip it, your agent stays half-blind.

Next steps

AI agent email MCP — full MCP install walkthrough
Why AI agents need email — the longer argument
Give your AI coding agent an email address — Claude Code, Cursor, Codex setup
Full command reference

Command references:

Per-PR ephemeral email inboxes for E2E tests in GitHub Actions

Qasim Muhammad — Mon, 04 May 2026 21:10:40 +0000

Your password-reset flow needs an inbox to test against. Your invitation flow too. Your email-verification gate too. The classic setup is a "test+pr-1234@yourdomain.com" alias on a shared mailbox, polling Gmail's API, hoping nothing else lands while the test runs. It is fragile, it leaks state across PRs, and your credentials live in CI.

A managed agent account flips this. Each PR gets a fresh inbox, lives only for the duration of the test run, and tears itself down at the end.

What this gives you

One inbox per PR, isolated from every other test
Real send/receive — not a mock
No shared Gmail credentials in CI
Cleanup is one command per inbox
Parallel test workers do not collide

The full GitHub Action

# .github/workflows/e2e.yml
name: E2E with ephemeral inbox

on:
  pull_request:
    branches: [main]

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Nylas CLI
        run: curl -fsSL https://cli.nylas.com/install.sh | bash
        env:
          NYLAS_INSTALL_DIR: ${{ github.workspace }}/.nylas

      - name: Authenticate
        run: $NYLAS_INSTALL_DIR/bin/nylas auth config --api-key ${{ secrets.NYLAS_API_KEY }}

      - name: Create ephemeral inbox
        id: inbox
        run: |
          EMAIL="e2e-pr${{ github.event.number }}-run${{ github.run_id }}@yourapp.nylas.email"
          $NYLAS_INSTALL_DIR/bin/nylas agent account create "$EMAIL" --json > inbox.json
          echo "email=$EMAIL" >> $GITHUB_OUTPUT
          echo "grant_id=$(jq -r .id inbox.json)" >> $GITHUB_OUTPUT

      - name: Run Playwright
        run: pnpm test:e2e
        env:
          E2E_INBOX: ${{ steps.inbox.outputs.email }}
          E2E_GRANT_ID: ${{ steps.inbox.outputs.grant_id }}

      - name: Tear down inbox
        if: always()
        run: $NYLAS_INSTALL_DIR/bin/nylas agent account delete ${{ steps.inbox.outputs.grant_id }} --yes

The if: always() on teardown makes sure the inbox is removed even when tests fail.

How the test reads mail

// tests/auth.spec.ts
import { test, expect } from '@playwright/test'
import { execFileSync } from 'node:child_process'

test('password reset email lands and link works', async ({ page }) => {
  const inbox = process.env.E2E_INBOX!
  const grantId = process.env.E2E_GRANT_ID!

  // 1. Trigger password reset
  await page.goto('/forgot-password')
  await page.fill('[name=email]', inbox)
  await page.click('button:has-text("Send reset link")')

  // 2. Poll the inbox for up to 30 seconds
  const link = await pollForResetLink(grantId, 30_000)
  expect(link).toMatch(/\/reset\/[a-f0-9-]+/)

  // 3. Click the link, verify the new-password form
  await page.goto(link)
  await expect(page).toHaveURL(/\/reset\//)
})

function pollForResetLink(grantId: string, timeoutMs: number): string {
  const deadline = Date.now() + timeoutMs
  while (Date.now() < deadline) {
    const out = execFileSync('nylas', [
      'email', 'list', '--grant', grantId, '--unread', '--limit', '5', '--json'
    ], { encoding: 'utf-8' })
    const messages = JSON.parse(out)
    for (const m of messages) {
      const match = (m.snippet || '').match(/https:\/\/[^\s]+\/reset\/[a-f0-9-]+/)
      if (match) return match[0]
    }
    require('node:child_process').execSync('sleep 2')
  }
  throw new Error('reset email never arrived')
}

Why this beats the alternatives

Approach	Per-PR isolation	No shared creds	Real inbox	Setup time
Mailosaur	✅	✅	✅	Paid SaaS
MailHog (self-hosted)	❌	✅	❌ (dev only)	Run a daemon
Gmail "+pr-1234" alias	Partial	❌	✅	OAuth setup
Agent accounts	✅	✅	✅	Two CLI commands

Mailosaur is excellent and used by many teams. The trade is the SaaS contract. Agent accounts ride your existing Nylas plan.

Parallel workers

GitHub Actions runs multiple PRs concurrently. Two PRs landing at the same time would clobber a shared inbox. Per-PR provisioning makes that a non-issue:

PR #1234 → e2e-pr1234-run-9999@yourapp.nylas.email
PR #1235 → e2e-pr1235-run-1000@yourapp.nylas.email

If you parallelise inside a single PR (e.g., matrix strategy), include the matrix index in the email:

strategy:
  matrix:
    shard: [1, 2, 3, 4]
steps:
  - run: |
      EMAIL="e2e-pr${{ github.event.number }}-shard${{ matrix.shard }}@yourapp.nylas.email"
      ...

Cost notes

Each agent account is one grant. Most plans bill on grants, so a 50-PR-a-week rate is 50 grants created and destroyed weekly. Cleanup is mandatory or you accumulate dead accounts. The if: always() step above takes care of that.

A real-world catch I hit

GitHub Actions runners do not have nylas on PATH after curl install.sh | bash — the binary is at $NYLAS_INSTALL_DIR/bin. Either add to PATH explicitly or invoke with the full path, as in the workflow above. I forgot this twice.

Next steps

E2E email testing with Playwright — the hands-on guide for password-reset and verification flows
Receive email without an SMTP server — production agent-account patterns
Create an AI agent email identity — full agent account walkthrough
Full command reference

Forem: Qasim Muhammad

Manage Nylas Applications, Connectors, and Grants from the CLI

What nylas admin does

Quick Start

Key commands

Creating an application and connector

Monitoring grants

Related posts

Agent Policies and Rules — Control What Your AI Agent Can Send and Receive

What policies and rules do

Quick Start

Key commands

Example: restrict outbound to internal domains only

Example: auto-archive marketing emails

Related posts

Manage Email Signatures from the CLI — Create, List, and Attach to Sends

What email signatures do

Quick Start

Key commands

Creating a signature from a file

Using a signature when sending

Related posts

Hosted Email Templates — Create, Render, and Send with Variable Substitution

What hosted templates do

Quick Start

Key commands

Rendering a preview before sending

Sending with a template

Local templates vs hosted templates

Related posts

Manage Booking Pages and Appointments from the Terminal

What nylas scheduler does

Quick Start

Key commands

Creating a booking page

Confirming a booking

Rescheduling

Related posts

Extract OTP Codes from Email in One Command — No Inbox Browsing

What nylas otp does

Quick Start

Key commands

Use in Playwright/Cypress tests

Watching for codes in real-time

Common issues

Related posts

Record and Transcribe Zoom, Meet, and Teams Meetings from the CLI

What nylas notetaker does

Quick Start

Key commands

Scheduling a recording for tomorrow

Retrieving the transcript

Common issues

Related posts

5 Nylas CLI commands every AI agent should have access to

1. nylas email send

2. nylas email list --json

3. nylas calendar events list

4. nylas contacts search

5. nylas agent account create

What I deliberately left off

How to install just these five

The takeaway

Next steps

Related posts

Send email from any Linux server in 60 seconds — no SMTP config

Why the old path is so slow

What the 60-second path skips

Real-world recipes

Cron job that emails on failure

systemd OnFailure handler

Deploy notification from CI

Shell trap on script exit

What about mailx, msmtp, sendmail?

The 60-second checklist

A note for hardened environments

Next steps

From Gmail OAuth hell to one-line agent identity

Attempt 1: dedicated Gmail account

Attempt 2: shared Gmail with a +alias

1. `nylas email send`

2. `nylas email list` `--json`

3. `nylas calendar events list`

4. `nylas contacts search`

5. `nylas agent account create`

What about `mailx`, `msmtp`, `sendmail`?

Attempt 3: `nylas agent account create`