Gmail send_email silently ignores from_address and sends from authenticated account

Summary

The Codex Desktop Gmail connector can silently ignore a caller-supplied from_address and send from the connector's authenticated account instead.

This is dangerous for workflows involving multiple Gmail identities because the tool reports success even though the actual RFC 5322 From header differs from the requested sender. It can cause unintended identity disclosure and external communication from the wrong account.

Environment

• Codex Desktop / ChatGPT desktop app: 26.825.51511 (build 7377)
• Platform: macOS
• Observed: 2026-08-31, America/New_York
• Component: Gmail connector send_email

Steps to reproduce

1. Authenticate the Gmail connector as account A.
2. Call the Gmail send_email action with from_address set to a different account B.
3. Observe that the tool returns success and the message receives the Sent label.
4. Read the sent message metadata or raw headers.
5. Observe that the actual From header is account A, not the requested account B.
6. Check account B's Gmail Sent folder; the message is absent.

The two account addresses and the external recipient are intentionally omitted from this public report.

Actual behavior

• Connector profile reported account A.
• The send call explicitly requested account B in from_address.
• The connector reported a successful send.
• Sent-message metadata showed From: ... <account A>.
• Account B's Sent folder contained no corresponding message.
• A corrective message had to be sent manually from account B.

Expected behavior

The connector should fail closed when the requested from_address is not the authenticated account or a verified, usable Gmail alias.

Acceptable behavior would be either:

1. Send from the requested address only when Gmail confirms it is an authorized send-as identity; or
2. Reject the call before sending with a clear error that names the authenticated account and explains that the requested sender is unavailable.

It must never silently substitute the authenticated account while reporting success.

Suggested acceptance criteria

• from_address is validated against Gmail's configured send-as identities before transmission.
• An unverified or unavailable sender causes a pre-send error and no message is created.
• The send result returns the actual sender identity used.
• The action exposes enough metadata for the caller to verify From, To, thread ID, and attachments after sending.
• Multi-account workflows fail closed when the intended account is ambiguous or inaccessible.
• Regression coverage includes authenticated account A plus requested account B.

Impact

This is more than a cosmetic mismatch. It can:

• disclose a personal address in professional or sensitive correspondence;
• misrepresent which identity authorized an external message;
• break audit trails and multi-account automations;
• cause duplicate corrective emails;
• undermine user trust in action confirmations.

Related issue

This is related to, but more severe than, #30418 (multiple named Gmail accounts). The specific defect here is silent sender substitution during a successful send.

Privacy

No email addresses, recipient information, message contents, OAuth data, message IDs, or raw logs are included. Redacted diagnostics can be provided privately if maintainers request them.

Start by locating the Gmail connector's send_email action and trace how from_address is handled before transmission. Check the sender validation and send-result metadata against the listed acceptance criteria. Done means unauthorized senders fail before sending, authorized identities are used correctly, the actual sender is returned, and regression coverage includes accounts A and B.