Problem
gmail.modify is the right OAuth scope for an AI agent that needs to read, label, and create drafts — but it also permits send. Google provides no scope that grants modify-level access without send capability. This means there is currently no way to give an AI agent read/label/draft access while maintaining a hard block on send.
A prompt-level guardrail is not sufficient: if safety instructions are compacted away during a long session, an agent operating on gmail.modify could send email on behalf of the user. The Summer Yue incident (February 2026) demonstrated what happens when an AI agent loses its instructions mid-execution due to context window compaction and defaults to its last understood objective — her problem was deletion, but the equivalent risk here is send.
Proposal
Add a --gmail-no-send global flag and GOG_GMAIL_NO_SEND env var that blocks all send operations in the gmail command group at the CLI layer, regardless of what OAuth scopes the token has.
Blocked paths
| Command path |
How it sends |
gog send (top-level alias) |
Direct compose + send |
gog gmail send |
Direct compose + send |
gog gmail drafts send <id> |
Sends existing draft |
gog gmail autoreply <query> |
Bulk auto-reply |
Non-send commands (unaffected)
watch serve, autoforward, vacation, filters, forwarding, sendas, delegates, drafts create, drafts update, and all read/organize commands continue to work normally.
Design
Follow the same centralized enforcement pattern as enforceEnabledCommands:
- Post-parse, pre-
Run() check in Execute()
- Inspects
kctx.Command() to identify send commands
- Returns
usagef(...) error (exit code 2) if blocked
- No auth/API calls needed — pure CLI-layer gate
Usage
# Flag
gog --gmail-no-send gmail send --to x@y.com --subject S --body B
# → "send blocked by --gmail-no-send (GOG_GMAIL_NO_SEND): use "gog gmail drafts create" to compose without sending"
# Env var (preferred for agent deployments)
GOG_GMAIL_NO_SEND=1 gog gmail send --to x@y.com --subject S --body B
# → same
# Non-send commands pass through
GOG_GMAIL_NO_SEND=1 gog gmail search "from:boss"
# → works normally
This gives agent operators a hard invariant they can rely on: deploy gog with GOG_GMAIL_NO_SEND=1 and send is impossible, full stop, regardless of what the agent is told or forgets.
Problem
gmail.modifyis the right OAuth scope for an AI agent that needs to read, label, and create drafts — but it also permits send. Google provides no scope that grants modify-level access without send capability. This means there is currently no way to give an AI agent read/label/draft access while maintaining a hard block on send.A prompt-level guardrail is not sufficient: if safety instructions are compacted away during a long session, an agent operating on
gmail.modifycould send email on behalf of the user. The Summer Yue incident (February 2026) demonstrated what happens when an AI agent loses its instructions mid-execution due to context window compaction and defaults to its last understood objective — her problem was deletion, but the equivalent risk here is send.Proposal
Add a
--gmail-no-sendglobal flag andGOG_GMAIL_NO_SENDenv var that blocks all send operations in the gmail command group at the CLI layer, regardless of what OAuth scopes the token has.Blocked paths
gog send(top-level alias)gog gmail sendgog gmail drafts send <id>gog gmail autoreply <query>Non-send commands (unaffected)
watch serve,autoforward,vacation,filters,forwarding,sendas,delegates,drafts create,drafts update, and all read/organize commands continue to work normally.Design
Follow the same centralized enforcement pattern as
enforceEnabledCommands:Run()check inExecute()kctx.Command()to identify send commandsusagef(...)error (exit code 2) if blockedUsage
This gives agent operators a hard invariant they can rely on: deploy gog with
GOG_GMAIL_NO_SEND=1and send is impossible, full stop, regardless of what the agent is told or forgets.