feat(gmail): add --inline and --text content modes to gmail attachment#5
Closed
chrischall wants to merge 1 commit into
Closed
feat(gmail): add --inline and --text content modes to gmail attachment#5chrischall wants to merge 1 commit into
chrischall wants to merge 1 commit into
Conversation
gog gmail attachment previously only wrote the attachment to a local file
and returned the path — a dead end for remote callers (MCP clients) that
cannot read the host filesystem.
- --inline: returns the content base64-encoded in a contentBase64 field
(JSON) for attachments up to 3 MiB; larger ones keep the path-only
behavior with an explanatory `reason` instead of failing silently.
- --text: returns extracted text in a `text` field — PDFs via a pure-Go
text extractor (with a `note` when the PDF is scanned/image-only),
HTML with tags stripped, plain text verbatim. Unsupported types return
a clear `reason`. Mutually exclusive with --inline.
- Both modes resolve filename/mimeType from the message payload, with a
single-attachment fallback (Gmail attachment IDs are not stable across
API responses) and content sniffing when metadata is unavailable.
- Default behavior (no new flags) is unchanged: {path, cached, bytes}.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Owner
Author
|
Reopened against upstream instead: openclaw#919 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
gog gmail attachment <messageId> <attachmentId>downloads the bytes, writes them to a local file, and returns only that path. When the caller is a remote MCP client (Claude), the path is unreadable — every attachment download is a dead end.Changes
--inline— returns the content base64-encoded in acontentBase64JSON field for attachments up to 3 MiB (maxInlineAttachmentBytes). Oversized attachments keep the existing path-only behavior plus an explanatoryreason, so callers get a clear signal instead of silently unusable output.--text— returns extracted text in atextfield:github.com/ledongthuc/pdf(pure Go, panic-guarded); anoteflags scanned/image-only PDFs with no text layer.gmailcontent.StripHTMLTags).reasonpointing at--inline/--out.--inline(usage error).filename/mimeTypefrom the message payload, with a single-attachment fallback — Gmail attachment IDs are not stable across API responses, so an exact ID match can miss — and content sniffing (%PDF-header,http.DetectContentType) when metadata is unavailable.{path, cached, bytes}), so existing local workflows are unaffected.gog gmail getwas checked for the same gap: bodies are already inlined (BestBodyText); only attachments resolve to IDs, which these flags now cover.Tests
TDD throughout (12 new command-level tests against the httptest Gmail API): small-attachment inline round-trip, oversize fallback with reason, default-output unchanged, flag mutual exclusion, PDF extraction (hand-assembled minimal PDF fixture), image-only PDF note, HTML tag-stripping, plain-text verbatim, unsupported-type reason, oversize text reason, unstable-attachment-ID metadata fallback, no-metadata content sniffing.
make lint testpasses. Live-verified against a real Gmail account: default/--text/--inlineon a real PDF attachment (text extracted; base64 round-trips to the exact original bytes) — both via the CLI and end-to-end through the gogcli-mcp stdio server.🤖 Generated with Claude Code