Gmail plugin corrupts local image attachments via raw MIME base64_url_content and lacks file-path attachment API

Severity

High / blocking for attachment workflows in Codex Desktop.

The current Gmail connector can send text emails, but it is effectively unusable for reliable local file attachments. Binary attachments sent via the current raw MIME base64_url_content path can be truncated/corrupted, producing broken image attachments for recipients.

Environment

• Product: Codex Desktop
• Gmail plugin: gmail version 0.1.5
• Gmail plugin manifest repository currently points to https://github.com/openai/oai-maintained-plugins, but that repository appears unavailable/non-public (GitHub issue creation returns 404).
• Gmail app connector id from .app.json: connector_2128aebfecb84f64a069897515042a44
• Date observed: 2026-07-25 Asia/Shanghai

Impact

This breaks a common and important workflow: asking Codex to email generated local artifacts such as PNG/JPEG mockups, screenshots, PDFs, or multi-file deliverables.

Previously, a path-based attachment interface such as attachment_files worked well for this type of workflow. The currently exposed Gmail _send_email schema only accepts a MIME tree with base64_url_content. There is no file_path, attachment_files, or tool-side local-file attachment parameter.

Because the model/tool invocation path has to carry the full base64 payload as text, the binary content can be truncated or otherwise corrupted before Gmail receives it.

Reproduction

1. Generate or use a local JPEG file in a Codex Desktop workspace.
2. Base64url encode it locally.
3. Call Gmail _send_email with a payload shaped like:

{
  "message": {
    "to": "recipient@example.com",
    "subject": "attachment test",
    "payload": {
      "mime_type": "multipart/mixed",
      "parts": [
        {
          "mime_type": "text/plain",
          "charset": "UTF-8",
          "body": { "content": "test" }
        },
        {
          "mime_type": "image/jpeg",
          "filename": "test.jpg",
          "content_disposition": "attachment",
          "body": { "base64_url_content": "<base64url bytes>" }
        }
      ]
    }
  }
}

1. Read the sent message back from Gmail and compare the attachment size/content to the source file.

Observed result

A local JPEG source file of 12,974 bytes was sent through _send_email via base64_url_content.

The sent Gmail message was created successfully, but reading the attachment back showed Gmail stored only 7,081 bytes.

Recipient reported receiving a tiny/broken gray image attachment instead of the actual image.

Example sent Gmail message id from the user's account:

• 19f97bc57ee30f54

Gmail search/read reported:

• has_attachment: true
• filename: api-plan-ui-four-screens-combined-email-tiny.jpg
• MIME type: image/jpeg
• stored size: 7081 bytes

Local source file:

• filename: api-plan-ui-four-screens-combined-email-tiny.jpg
• local size before sending: 12974 bytes

Expected result

The connector should preserve the exact binary attachment bytes and recipients should receive a valid, uncorrupted attachment.

For local Codex workflows, the connector should expose a file-path based attachment API so the tool/runtime can read and stream/encode the file safely outside the model text channel, for example:

{
  "attachment_files": ["/absolute/path/to/file.jpg"]
}

or

{
  "attachments": [
    { "path": "/absolute/path/to/file.jpg", "content_disposition": "attachment" }
  ]
}

Suggested fix

Please restore/add a path-based attachment interface for Gmail send/draft/update flows, or provide a dedicated attachment upload/file handle mechanism that does not require the model to inline raw base64 content in the tool call.

At minimum, the connector should document the practical payload limits for base64_url_content and warn that it is not suitable for local artifact attachments.

User expectation

The user considers this severe enough that if it is not fixed promptly, they will stop using the Gmail plugin for attachment workflows and switch to another mail delivery channel.