Gmail connector generates nondeterministic Date timezone offsets unrelated to sender timezone

Summary

The Codex Desktop Gmail connector generates RFC 5322 Date headers with timezone offsets that are unrelated to the sender's local timezone and are not even consistent between requests.

In three controlled self-sends from the same Codex session and Gmail account:

• two messages used -0700;
• one message used -0500;
• two messages sent only three seconds apart used different offsets.

All timestamps represent the correct UTC instant. This is therefore not a clock or delivery failure; it is nondeterministic timezone metadata. A native Gmail web control from the same account correctly used America/Toronto (-0400).

Standards context

RFC 5322 section 3.3 says the date and time-of-day SHOULD express local time. Section 3.6.1 defines Date as the origination time when the creator considers the message complete and ready for delivery.

This report does not claim that the messages are syntactically invalid or that their UTC instants are incorrect. The issue is that an infrastructure-dependent timezone is being serialized into an originator field instead of the sender's timezone or a deterministic neutral fallback.

Environment

• Codex Desktop: 26.814.41407
• Codex build: 6720
• Gmail plugin package: 0.1.8
• macOS: 26.5.1 (build 25F80)
• System timezone: America/Toronto
• Expected local offset on test date: -0400
• Test date: 2026-08-20
• Same authenticated Gmail account used for connector and Gmail web control

Minimal connector request

The connector was asked to send a plain-text message to the authenticated account itself:

{
  "to": "me",
  "subject": "Gmail timezone test",
  "payload": {
    "mime_type": "text/plain",
    "charset": "UTF-8",
    "body": {
      "content": "Controlled timezone test"
    }
  }
}

No Date or Message-ID header was supplied by the caller.

Steps to reproduce

1. Set the system timezone to America/Toronto.
2. In Codex Desktop, use the Gmail connector to send a plain-text email to the authenticated account.
3. Do not provide Date or Message-ID.
4. Repeat the connector send at least three times.
5. Send one control message from Gmail web using the same account and browser/system timezone.
6. Read each message using Gmail's full or raw representation.
7. Compare the RFC 5322 Date value with Gmail's internalDate.

Controlled results

| Path | RFC 5322 Date | UTC instant from internalDate | Toronto local time |
|---|---|---|---|
| Connector run 1 | Thu, 20 Aug 2026 00:33:21 -0700 | 07:33:21Z | 03:33:21 -0400 |
| Connector run 2 | Thu, 20 Aug 2026 00:58:02 -0700 | 07:58:02Z | 03:58:02 -0400 |
| Connector run 3 | Thu, 20 Aug 2026 02:58:05 -0500 | 07:58:05Z | 03:58:05 -0400 |
| Native Gmail web control | Thu, 20 Aug 2026 04:02:59 -0400 | 08:02:59Z | 04:02:59 -0400 |

Connector runs 2 and 3 were sent three seconds apart but used -0700 and -0500, respectively.

Example connector trace header:

Received: from 77377267392 named unknown
        by gmailapi.google.com
        with HTTPREST;
        Thu, 20 Aug 2026 00:58:02 -0700

The transport server's Received timezone is included only as diagnostic evidence. Changing Received headers is not part of this request; transport infrastructure may use its own timezone.

Observed behavior

• Connector result: 2/3 messages used -0700; 1/3 used -0500.
• Native Gmail web result: -0400, matching the sender's local timezone.
• Gmail internalDate remained correct in all cases.
• Timezone-aware clients can normalize these values to the correct instant, so this report does not claim a three-hour chronology error.
• Raw-message review, audit tooling, and timezone attribution nevertheless receive inconsistent originator metadata.
• The result suggests different backend executions may inherit different local timezone settings, but that is an inference rather than a confirmed root cause.

Expected behavior and acceptance criteria

1. When the sender's timezone is available, the generated Date header consistently uses that timezone and correct DST offset.
2. When the sender's timezone is unavailable, the connector uses a documented, deterministic neutral representation such as UTC rather than an arbitrary worker-local offset.
3. Repeated sends from the same session do not vary between unrelated timezone offsets.
4. The absolute instant represented by Date continues to match the message creation time and Gmail internalDate.
5. Native Gmail and connector-generated messages from the same account no longer expose conflicting originator timezone behavior.
6. No change is required to server-generated Received trace headers.

Impact

• Raw headers can incorrectly suggest that the message creator was operating in a different timezone.
• Audit and forensic workflows receive nondeterministic originator metadata.
• Connector messages behave differently from native Gmail messages sent from the same account.
• The variability makes the behavior difficult for clients and users to reason about, even though delivery and chronological ordering remain correct.