## Summary When sending an email through the Codex Desktop Gmail connector, a sender display name containing non-ASCII characters can be mis-encoded in the `From` header. Example expected sender display name: ```text Example É User ``` Example actual sender display name observed in Gmail sent mail: ```text "Example Ã‰ User" ``` The email body handles UTF-8 correctly. For example, the body can contain: ```text Example É User ``` But the sender display

Gmail connector mis-encodes non-ASCII sender display name in From header

Resolved 💬 2 comments Opened May 20, 2026 by vgbento Closed Jun 1, 2026

Summary

When sending an email through the Codex Desktop Gmail connector, a sender display name containing non-ASCII characters can be mis-encoded in the From header.

Example expected sender display name:

Example É User <user@example.com>

Example actual sender display name observed in Gmail sent mail:

"Example Ã‰ User" <user@example.com>

The email body handles UTF-8 correctly. For example, the body can contain:

Example É User

But the sender display name in the message metadata/header is corrupted.

Steps to reproduce

Configure a Gmail sender display name with a non-ASCII character, such as Example É User.
In Codex Desktop, use the Gmail connector to send an email.
Open the sent message in Gmail or read it back through the Gmail connector.
The From display name appears mojibaked, for example Example Ã‰ User, instead of preserving the original UTF-8 text.

Observed behavior

The From display name appears to be UTF-8 text interpreted as Latin-1/Windows-1252.

Example connector readback after sending:

from_: "\"Example Ã‰ User\" user@example.com"
body: "Test message\n\nExample É User"

Expected behavior

The Gmail connector should preserve UTF-8 characters in the sender display name, so the sent message should show the configured non-ASCII display name correctly.

Notes

This was reproduced using Codex Desktop with the Gmail connector. The body content preserved the non-ASCII text correctly; only the sender display name/header path was affected.

View original on GitHub ↗

2 Comments

tulior · 3 months ago

I can confirm this is not limited to Codex Desktop.

I reproduced the same Gmail connector bug through ChatGPT using the Gmail connector send path from both:

ChatGPT web at chatgpt.com
ChatGPT iOS app

In both cases, the body preserves UTF-8 correctly, but the sender display name in the raw From header is mojibaked.

Example from ChatGPT iOS repro:

Received: from 77377267392 named unknown by gmailapi.google.com with HTTPREST; Wed, 20 May 2026 10:48:00 -0500
Subject: Um poema simples
Content-Type: multipart/alternative; boundary="===============7831536496047008588=="
Date: Wed, 20 May 2026 10:48:00 -0500
From: "TÃºlio Ribeiro dos Anjos" <redacted>
````

Same message body preserves UTF-8 correctly:

```text
Meu amor, Lívia,

...

Com muito amor,
Túlio

So this appears to be isolated to MIME/header construction for the sender display name, not body encoding.

Reproducibility: for my account, this appears to happen on every email sent through the ChatGPT Gmail connector where the configured sender display name contains ú. I do not see the issue when sending outside the connector path.

Expected behavior would be RFC 2047-compatible header serialization, e.g. an encoded-word form equivalent to:

From: =?UTF-8?B?VMO6bGlvIFJpYmVpcm8gZG9zIEFuam9z?= <redacted>

This suggests the bug may be in a shared Gmail connector / MIME serialization layer, not only in Codex Desktop.

tulior · 2 months ago

I can confirm this is working as expected now.