What a Gmail Extension Can Actually See (and What OAuth Grants)

An extension asks to “read, compose, send, and permanently delete all your email from Gmail”. You click Allow, because you wanted the follow-up reminders and the dialog is in the way.

That sentence is not marketing hyperbole — it’s a fair description of a common OAuth scope. This is about what Gmail extension permissions actually grant, the completely different mechanism some extensions use instead, and how to tell which one you’re installing.

Two different ways to read your mail#

Almost every Gmail tool uses one of two mechanisms. They sound similar and are not remotely equivalent.

	OAuth / Gmail API	Content script
What it accesses	Your mailbox, server-side	The page you’re looking at
Works when browser closed	Yes	No
Can read old mail you haven’t opened	Yes, all of it	Only what’s rendered
Can send mail as you	If granted	Only by driving the interface
Data leaves your machine	Usually, to their server	Only if the extension chooses to send it
Revoked by	Google Account permissions	Uninstalling the extension

The OAuth route#

You’re redirected to Google, shown a consent screen, and you grant an application access to your account. The extension then talks to Gmail’s servers directly using a token.

This is the standard, well-designed way to build a mail integration, and there is nothing shady about it in itself. It’s how scheduling tools, CRMs and mail clients work, and it’s the only way to do things like sending a follow-up while your laptop is shut.

What matters is which scopes were requested. They differ enormously:

• gmail.readonly — read all mail and settings. Cannot send or delete.
• gmail.send — send mail as you. Cannot read.
• gmail.modify — read, write and modify, including labels. Cannot permanently delete.
• gmail.metadata — headers only: who, when, subject. No message bodies.
• https://mail.google.com/ — full access, including permanent deletion. This is the broadest one.

A follow-up tool genuinely needs to read threads and probably to send. It rarely needs full-mailbox delete rights. When you see the broadest scope requested for a narrow feature, that’s worth a pause — not because the developer is malicious, but because breadth increases the blast radius if they’re ever compromised.

The part people miss#

Granting OAuth access means a copy of your mail can end up on someone else’s server, because that’s usually where the processing happens. Your data is then subject to their security, their retention policy, their jurisdiction and their next acquisition.

Google runs a verification process for apps requesting sensitive Gmail scopes, including security assessments for the most sensitive ones. That’s a real check and it is not a guarantee about what happens to your data afterwards.

The content-script route#

A Chrome extension can run JavaScript in the context of a page you have open. An extension built this way sees the Gmail interface the same way you do — the threads currently rendered in your browser — and nothing else.

What this means concretely:

• No Google account access. Nothing appears in your Google Account permissions list, because nothing was granted there.
• No server-side reach. The extension cannot read a message you’ve never opened, because it isn’t talking to Gmail’s servers at all.
• Nothing happens while you’re away. Close the browser and the extension stops existing.
• Data can stay local. It can, if the extension stores it in your browser profile. It doesn’t have to — a content script can still upload whatever it reads.

That last point is the honest caveat. A content script is a narrower capability, not automatically a privacy guarantee. The right question isn’t only “what can it reach” but “where does what it reads go”.

The trade-offs, plainly#

Neither approach is simply better:

• OAuth buys you reach. Scheduled sending, server-side processing, working across devices, seeing mail you’ve never opened. If you need any of that, a content script cannot provide it.
• A content script buys you containment. Smaller surface, nothing granted at the account level, and the possibility of everything staying on your machine.

The question is whether the tool’s features require the reach it’s asking for. A follow-up tool that surfaces threads you’re already looking at doesn’t need server-side access to your entire mail history — and if it asks for it anyway, the mismatch is the interesting part.

How to check what you’ve already granted#

Worth ten minutes today:

1. Open your Google Account → Security → Third-party apps with account access. Every app with a token is listed, with its scopes.
2. Look for anything you don’t recognise or no longer use. Trials from two years ago are still there.
3. Remove access for anything you can’t justify. Revocation is immediate.
4. Then check chrome://extensions separately — an extension with no OAuth grant won’t appear in the Google list at all, so these are two different audits.

People frequently find that the tool they stopped using in 2023 still holds read access to their mailbox.

Questions worth asking before you install#

• Does it ask for OAuth? If yes, which scopes, and do they match what it does?
• Where is my data processed? On my machine, or on their server?
• What’s stored, and for how long?
• What happens when I uninstall? Local storage goes with the extension; server-side copies do not.
• Does it need to work while I’m offline? If not, it doesn’t need server access.
• Is there an AI feature, and where does it run? “Summarise this thread” can mean on-device or a round-trip to a provider with your email in the request body. Those are very different, and worth understanding.

If a company can’t answer these clearly on its own site, that itself is the answer.

Why we chose the narrow route#

To be transparent about our own position: CommitLatch uses no Gmail OAuth at all. It reads the thread content already rendered in your browser via a content script, stores its queue in your local Chrome profile, and runs its AI on-device by default. There is nothing in your Google Account permissions list to revoke, because nothing was granted.

That’s a deliberate trade with real costs: it can’t do anything while your browser is closed, it can’t reach mail you’ve never opened, and it doesn’t sync between machines. For a follow-up tool we think that’s the right side of the trade — but it is a trade, and you should pick the side that matches what you actually need it to do.

Gmail extension permissions FAQ#

What does a Gmail extension actually get access to?

It depends entirely on the mechanism. An extension using OAuth and the Gmail API is granted server-side access to your mailbox under specific scopes, and can read mail you have never opened even when your browser is closed. An extension using a content script only sees the page currently rendered in your browser.

Which OAuth scopes should I be cautious about?

The broadest one grants full access including permanent deletion. Narrower scopes exist for read-only access, sending only, modification without deletion, and metadata only. The question worth asking is whether the scope requested matches what the tool actually does — a follow-up tool rarely needs full mailbox delete rights.

Is a content-script extension automatically safer?

It has a narrower capability, which is not the same as a guarantee. A content script cannot reach mail you have never opened and holds no account-level grant, but it can still upload whatever it does read. The right question is both what it can reach and where what it reads goes.

How do I check what I have already granted?

Open your Google Account, then Security, then third-party apps with account access. Every app holding a token is listed with its scopes, and revocation is immediate. Check chrome://extensions separately — an extension with no OAuth grant will not appear in the Google list at all, so these are two different audits.

Does uninstalling an extension remove my data?

It removes anything stored locally in the browser profile. It does not remove copies held on a developer’s server, and it does not by itself revoke an OAuth grant. If a tool had account access, revoke it in your Google Account as a separate step.

What if the extension has AI features?

Ask where the model runs. “Summarise this thread” can mean an on-device model or a network request with your email in the body, sent to a provider or to the developer’s own server. Those are very different arrangements, and a tool that does not say clearly which one it uses has answered the question.