Cursor shipped plugins for Gmail, Drive and Calendar on 3 August.
A code editor that reads your email sounds like scope creep. It is closer to an admission: most of the information needed to write the right code is not in the repository.
The context problem these solve
The reason a feature gets built wrong is rarely that the model wrote bad code. It is that the requirement lived in a thread, a spec document, or a decision made in a meeting nobody wrote down.
Drive holds the spec. Gmail holds the thread where the requirement changed. Calendar holds the meeting where it was decided. Pulling from those is the same instinct behind MCP in Copilot code review, which went GA on 29 July — give the tool the context a human colleague would already have.
Cursor's direction is now unmistakable
Slack improvements on 17 July, iPad on 29 July, Google Workspace on 3 August.
Three integrations in three weeks, all pointing outward from the editor toward where work is actually discussed. Cursor is not trying to be the best place to type code. It is trying to be present wherever a decision about code gets made.
What to check before enabling
This is a broader grant than a repository connection, and it deserves a moment of thought rather than a reflexive approval.
- Workspace access is per-account — a plugin connected on a personal account can reach mail that has nothing to do with work
- Decide whether the connection is read-only in practice, and prefer the narrowest scope the plugin offers
- If your organisation has a data classification policy, mail and Drive are almost certainly covered by it; check before connecting, not after