feat(gmail): add --gmail-no-send flag for agent safety

[veteranbv]

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.

[codefly]

@veteranbv Thanks for this!

I do have a use case which isn't covered by this PR. Adding this per-account.

The particular case here - I want my agent to have it's own email account which he's allowed to send from
He also has access to my email account, but only has access to compose drafts for me, not send them. (hard

[veteranbv]

@codefly Thank you for this. Really good point I hadn't considered. I was focused on blocking everything globally since that's my use case, but you're right that per-account control matters. Your scenario (agent's own email can send, personal account is draft-only) is exactly why this needs to be configurable.

I've updated the PR to support both:

Global kill switch (unchanged): --gmail-no-send / GOG_GMAIL_NO_SEND=1 blocks all send regardless of account. Also available as a config key via gog config set gmail_no_send true for persistence without env vars.

Per-account config (new): no_send_accounts in config.json, managed via:

gog config no-send set personal@gmail.com      # block send for this account
gog config no-send remove personal@gmail.com   # allow send
gog config no-send list                        # show blocked accounts

The per-account check runs inside each send command's Run() after account resolution, since account identity isn't known until requireAccount() resolves aliases and defaults. The global flag still enforces earlier in Execute() as an unconditional override.

Precedence: CLI flag > env var > config key (gmail_no_send) > per-account config (no_send_accounts) > default (allow).