The CLI-First Way to Manage Agent Accounts

Nylas released a CLI-first approach to managing Agent Accounts, hosted mailboxes that applications can own end-to-end. The Nylas CLI enables developers to create, monitor, and tear down email identities entirely from the terminal, with commands for account creation, email operations, and calendar management. The tool supports JSON output for automation and includes features like IMAP/SMTP access and natural-language scheduling.

There's a specific kind of friction in provisioning infrastructure through a web UI: you're building an automated system, but step one is clicking through a dashboard. For email identities that your code creates, monitors, and tears down, the browser is the wrong tool. The Nylas CLI closes that gap — every part of an Agent Account's lifecycle is a terminal command. Agent Accounts currently in beta are hosted mailboxes with real addresses that your application owns end-to-end. They send, receive, and hold calendar events like any human account, and the quickstart https://developer.nylas.com/docs/v3/getting-started/agent-accounts/ gets you from API key to working mailbox in under 5 minutes. Here's how to do all of it without leaving the shell. If you've never touched the CLI before: brew install nylas/nylas-cli/nylas or, without Homebrew: curl -fsSL https://cli.nylas.com/install.sh | bash nylas init nylas init opens a browser once for account creation and sign-in — the only step that needs a human. After that, verify with nylas auth whoami --json , which returns your active grant, provider, and status as parseable JSON. If you already have an API key, skip the browser entirely with nylas init --api-key <NYLAS API KEY add --region eu for EU data residency . Want to confirm the binary works before wiring up credentials? nylas demo email list returns sample data with no authentication at all — useful in provisioning scripts that should fail fast if the install step broke. With a domain registered either your own with MX and TXT records, or a .nylas.email trial subdomain for instant testing , creation is one line: nylas agent account create agent@yourdomain.com The CLI prints the new grant ID plus status and connector details. That grant ID is the handle for everything else — messages, calendar, webhooks. Want a human to supervise the mailbox from Outlook or Apple Mail? Create it with IMAP/SMTP access enabled: nylas agent account create agent@yourdomain.com --app-password "MySecureP4ssword 2024" Three commands cover the "what do I have and is it working" questions: nylas agent account list --json every Agent Account on the application nylas agent account get agent@yourdomain.com one account, by ID or email nylas agent status --json connector readiness Accounts also show up in nylas auth list with Provider: Nylas , side by side with any OAuth-connected grants. Switch between them with nylas auth switch , and the regular email and calendar commands operate on whichever is active: nylas email list --limit 5 --json nylas email send --to "you@example.com" --subject "Hi" --body "From the agent." --yes nylas calendar events list --days 7 --json Note the flags. The autonomous agents guide https://developer.nylas.com/docs/v3/getting-started/cli-for-agents/ is blunt about this: always pass --json for parseable output, always pass --yes on sends and deletes so nothing blocks on a confirmation prompt, and always pass --limit start with 5 so list commands don't flood whatever's consuming the output. Once an account exists, the everyday email commands go well beyond list-and-send. Search, read a specific message, and even schedule delivery for later: nylas email search "meeting agenda" --limit 5 --json nylas email read <MESSAGE ID --json nylas email send \ --to "alice@example.com" \ --cc "bob@example.com" \ --subject "Project update" \ --body "Status report attached." \ --schedule "tomorrow 9am" \ --yes The calendar side has a similar range — list events, create them with explicit timestamps, or find a slot that works for multiple people: nylas calendar find-time \ --participants "alice@example.com,bob@example.com" \ --duration 30m \ --json nylas calendar schedule ai "Find 30 minutes with Alice next week" That last one is natural-language scheduling: you hand it a sentence, it works out the slot. All of these operate on whichever grant is active, so they work identically against an Agent Account and a human's OAuth-connected mailbox. Policies and rules — the guardrails that control send limits, spam handling, and inbound filtering — are inspectable the same way: nylas agent policy list nylas agent rule list And webhooks, so your code reacts to inbound mail in real time: nylas webhook triggers see what you can subscribe to nylas webhook create \ --url https://youragent.example.com/webhooks/nylas \ --triggers "message.created,message.updated" nylas webhook list These work against any grant, connected or agent-owned. Ephemeral identities only make sense if destruction is as cheap as creation: nylas agent account delete agent@yourdomain.com --yes Delete by email or by grant ID; --yes skips the confirmation so it's scriptable. The failure modes are predictable enough to script around. The autonomous agents guide ships a troubleshooting table; here's the short version: | Symptom | Fix | |---|---| nylas: command not found | Re-run the install, or use the full path /opt/homebrew/bin/nylas | error.type: "unauthorized" | Run nylas dashboard apps apikeys create to mint a new API key | not found error on a grant | Run nylas auth login to reconnect | rate limit error | Back off and retry | | Commands hang | You forgot --yes on a send or delete | | Empty results | nylas auth list to check accounts, nylas auth switch to change | Errors come back in the same JSON envelope as the API — a request id plus an error object with type and message — so a script can branch on error.type instead of grepping prose. The dashboard is fine for a first look. The CLI wins everywhere else: create command in a setup script is documentation; a sequence of dashboard clicks isn't. --json output and non-interactive --yes flag exist precisely so an autonomous process never hangs on a prompt. nylas auth token prints the raw API key and nylas auth whoami --json gives you the grant ID — two commands and your .env is populated.There's also an escape hatch in both directions. Everything the CLI does maps to plain API calls account creation is POST /v3/connect/custom with "provider": "nylas" , so you can graduate to SDK code whenever a script outgrows the shell. And if your editor or agent speaks MCP, nylas mcp install registers 16 email, calendar, and contacts tools so you skip subprocess calls entirely. Next step: register a trial domain, run nylas agent account create test@your-application.nylas.email , and send yourself a message from it. Total elapsed time should be a coffee refill. Then check nylas agent status --json and see what a healthy connector looks like before you build anything on top.