Gmail: cannot send emails with attachments (--json arg limit, --upload wrong content type)

[0xBigBoss]

Problem

There's no way to send a Gmail message with an attachment using gws. Two approaches fail:

1. --json with base64url-encoded raw MIME — hits OS argument length limit

The documented approach for sending raw MIME (with threadId, In-Reply-To, References headers, and attachments) is to base64url-encode the entire message and pass it via --json '{"raw": "..."}'. But even a modest ~577KB PDF attachment produces a ~1MB base64 payload, which exceeds macOS's ~256KB ARG_MAX for command-line arguments:

gws-behav gmail users messages send --params '{"userId": "me"}' --json "{\"threadId\": \"...\", \"raw\": \"$RAW\"}"
# => zsh: argument list too long: gws

2. --upload with raw MIME file — wrong content type

Gmail's /upload/gmail/v1/users/me/messages/send endpoint accepts message/rfc822 for media uploads. But --upload wraps the file in multipart/related with an auto-detected content type, which Gmail rejects:

gws gmail users messages send --params '{"userId": "me", "uploadType": "media"}' --upload message.eml
# => Media type 'multipart/related; boundary=gws_boundary_...' is not supported.

Suggested fixes

Any of these would unblock the use case:

1. --json-file <PATH> or --json @<PATH> — read JSON body from a file (like curl -d @file.json)
2. --json - — read JSON body from stdin
3. --upload-type <MIME> — let users override the content type for --upload (e.g. --upload-type message/rfc822)
4. Auto-detect .eml → message/rfc822 in --upload content type detection

Options 1 or 2 are the most general and would help any API method with large request bodies, not just Gmail.

Environment

• gws 0.4.4
• macOS Darwin 25.3.0 (arm64)

Related

• Feature request: first-class reply and forward support for Gmail #88 — first-class reply/forward support would also solve this at a higher level
• Bug: Out-Of-Memory (OOM) Crash on Large File Uploads (Google Drive/YouTube) #244 — OOM on large file uploads (related large-payload issue)

[chrisvariety]

workaround @ #276 (comment) for --json to accept @file