Nylas CLI - Email, calendar, and contacts for AI agents
byā¢
Nylas CLI gives AI agents a real email account, working calendar, and contact across Gmail, Outlook, Exchange, Yahoo, iCloud, and IMAP through one auth flow
Replies
Best
Hunter
š
Hey Product Hunt ā Qasim from Nylas here.
We built Nylas CLI because every AI agent demo I saw was hitting a wall the same way: "your agent can read your inbox" turned into 200 lines of OAuth code, a Gmail-only integration, and a token refresh bug three days later.
So we shipped one binary that solves it for 6 providers Gmail, Outlook, Exchange, Yahoo, iCloud, IMAP through a single auth flow. Run `nylas mcp install` and Claude/Cursor/your agent of choice gets 16 tools: send mail, search threads, create events, look up contacts, the lot.
A few things we got obsessed with: - One auth flow: OAuth for Google/Microsoft, app passwords for Yahoo/iCloud, server config for Exchange all hidden behind `nylas auth`. You never write provider-specific code. - MCP native: The CLI is the MCP server. No second binary, no daemon. Tools are typed, errors are structured, agents handle them well. - Open source: MIT, written in Go, single static binary. No telemetry, no signup wall.
Would love feedback especially from anyone building agents that need email/calendar access. What's the workflow we should optimize for next?
Use CLI today to connect your email Command: nylas init
Report
How do you handle all the 2FA and frequent logouts imposed by organizational policies?
Report
Hunter
@lakshminath_dondetiĀ Nylas handles OAuth token refresh server-side, the CLI authenticates once via OAuth, Nylas stores and auto-refreshes the tokens, so the cli never sees 2FA prompts or session timeouts after initial setup. The org's login policies apply to the initial OAuth consent, not to ongoing API access
Report
Congrats on the launch š Quick question: when an agent sends an email through Nylas CLI, does it appear as the user, the agent, or a delegated identity?
the oauth problem kills most email agent projects before they start. solid solve
Report
the agent layer for email + calendar is where a lot of audit conversations land. when an agent emails on behalf of a user, the question regulators are starting to ask is which trace produced which message.
how do you think about identity attribution for the agent's actions?
Replies
Hey Product Hunt ā Qasim from Nylas here.
We built Nylas CLI because every AI agent demo I saw was hitting a wall the same way: "your agent can read your inbox" turned into 200 lines of OAuth code, a Gmail-only integration, and a token refresh bug three days later.
So we shipped one binary that solves it for 6 providers Gmail, Outlook, Exchange, Yahoo, iCloud, IMAP through a single auth flow. Run `nylas mcp install` and Claude/Cursor/your agent of choice gets 16 tools: send mail, search threads, create events, look up contacts, the lot.
A few things we got obsessed with:
- One auth flow: OAuth for Google/Microsoft, app passwords for Yahoo/iCloud, server config for Exchange all hidden behind `nylas auth`. You never write provider-specific code.
- MCP native: The CLI is the MCP server. No second binary, no daemon. Tools are typed, errors are structured, agents handle them well.
- Open source: MIT, written in Go, single static binary. No telemetry, no signup wall.
Would love feedback especially from anyone building agents that need email/calendar access. What's the workflow we should optimize for next?
ā https://cli.nylas.com ā https://github.com/nylas/cli
Use CLI today to connect your email
Command: nylas init
@lakshminath_dondetiĀ Nylas handles OAuth token refresh server-side, the CLI authenticates once via OAuth, Nylas stores and auto-refreshes the tokens, so the cli never sees 2FA prompts or session timeouts after initial setup. The org's login policies apply to the initial OAuth consent, not to ongoing API access
@francesco2689Ā Thanks, Yes its just an email, but this email comes with rules and policy and you can give to agent example https://cli.nylas.com/guides/stop-ai-agent-going-rogue
the oauth problem kills most email agent projects before they start. solid solve
the agent layer for email + calendar is where a lot of audit conversations land. when an agent emails on behalf of a user, the question regulators are starting to ask is which trace produced which message.
how do you think about identity attribution for the agent's actions?
@vivek_warrantĀ
- Audit AI Agent Activity (https://cli.nylas.com/guides/audit-ai-agent-activity) ā covers nylas audit logs show with grant, command, request ID tracing
- Create an AI Agent Email Identity (https://cli.nylas.com/guides/create-ai-agent-email-identity) ā covers giving agents their own provider=nylas managed identity separate