Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/agent-email/issues.md or /mcp/agent-email/issues.json, or Pod over MCP.

Reported issues for Agent Email

Pod holds 21 of 75 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Agent Email.

Most discussed

ops: complete Google OAuth verification for gmail.modify

Current state

Google Auth Platform project email-agent-mcp-gmail (160133826181) is External and In production, with verified branding. The Gmail API and billing are enabled.

The July 23, 2026 Console export shows:

Read the thread · 2026-07-22 · open · 4 comments

Wire strip_signatures from read_email action through to MCP tool

Summary

The read_email MCP tool currently does not expose the strip_signatures parameter that the underlying readEmailAction already supports. This follow-up was deferred from #76 (out-of-scope per the original issue) and is now unblocked since #76 refactored MCP read_email to be a thin adapter over readEmailAction.run().

Background

After #76 landed, packages/email-mcp/src/server.ts read_email delegates to readEmailAction.run() but hardcodes strip_signatures: false for

Read the thread · 2026-05-08 · closed · 3 comments

Dead in-memory mailboxStore in email-core: four unreachable actions the MCP server bypasses with a 10-line apology

Summary

packages/email-core/src/actions/configure.ts maintains an in-memory mailboxStore (configure.ts:20) read/written by configureMailboxAction, removeMailboxAction, and listMailboxesAction (configure.ts:116), and getMailboxStatusAction (packages/email-core/src/actions/status.ts:52) reads the same store via getMailboxStore() (status.ts:4,62). No production code path ever populates that store, so all four actions are unreachable dead code:

Read the thread · 2026-08-11 · closed · 2 comments

Expose the existing list_mailboxes action in the public MCP tool surface

Summary

The repository already contains a list_mailboxes action and a matching specification, but it does not appear to be exposed as an MCP tool in the public server surface. As a result, an MCP client inspecting the available tools today cannot enumerate configured mailboxes without falling back to undocumented behavior (e.g. calling get_mailbox_status with no mailbox argument and inspecting what it returns — which, on inspection of the code, returns the default mailbox's status, not

Read the thread · 2026-05-20 · closed · 2 comments

Add scheduled send (deferred delivery) for outbound email

Summary

The MCP server can create drafts and send messages immediately, but has no way to schedule a message to be delivered at a future time. Users who want "send Friday at 8 AM" or "hold this until tomorrow morning so it lands at the top of the recipient's inbox" currently have to either click around the Outlook UI manually or roll their own Graph calls.

This is a common pattern when an agent assists with outbound communication on a deadline (e.g., "draft this and queue it for tomorrow mor

Read the thread · 2026-04-28 · closed · 2 comments

Normalize provider errors at the provider boundary: terminal 4xx codes, 429 retryAfter, and SEND_STATUS_UNKNOWN for ambiguous delivery failures

Follow-up to #173 (scoped out of its fix PR deliberately).

Today, thrown provider errors bypass the ProviderError code/recoverable taxonomy on the most common failure paths:

Read the thread · 2026-08-11 · closed · 1 comment

Block unsafe body replacement on partially created Outlook reply drafts

Problem

A partially created Outlook reply draft can lose its provider-generated quoted history when the caller tries to recover with update_draft(body=...).

Observed sequence:

  1. Outlook's reply-draft operation creates a threaded draft shell.
  2. Adding the reply text fails (in the observed case, with HTTP 403), leaving the partial reply draft in the mailbox.
  3. The caller retries by updating the surviving draft's body.
  4. update_draft treats body as complete replacement content and r

Read the thread · 2026-08-04 · closed · 1 comment

update_draft: editing the body of a reply draft is unsafe — one build silently keeps stale content, the other silently destroys the quoted thread

Summary

update_draft cannot safely edit the body of a reply draft today, and both existing behaviours fail silently in opposite directions:

Read the thread · 2026-07-29 · closed · 1 comment

Most recent

Outlook attachment download can fail when a host shortens long REST IDs

Problem

Some MCP hosts can expose Microsoft Graph's long default REST IDs with a middle segment missing. Passing that altered message or attachment ID back to download_attachment makes Graph return ErrorInvalidIdMalformed.

Reproduction evidence

Read the thread · 2026-08-27 · closed · 0 comments

send_email: non-ASCII Subject is not RFC 2047-encoded and ends up triple UTF-8 encoded (mojibake); body is fine

Summary

When sending mail whose Subject contains non-ASCII characters (e.g. CJK), the delivered Subject: header is garbled. The body is encoded correctly (quoted-printable UTF-8), so this is specific to header handling. Two defects combine:

  1. The Gmail provider never RFC 2047-encodes header values — non-ASCII subjects are placed raw into the header.
  2. The subject string is additionally double-encoded upstream before it reaches the provider, so the bytes on the wire are *

Read the thread · 2026-08-24 · open · external user · 0 comments

create_draft unnecessarily requires to when reply_to can derive recipients

Summary

create_draft requires an explicit to value even when reply_to is supplied:

MISSING_FIELD: to is required — provide it as a parameter or in body_file frontmatter

That requirement is redundant on a threaded reply. The provider already knows the parent message and can derive the sender-only or reply-all recipient set from reply_to plus reply_all.

This is the remaining edge after #164. That issue correctly fixed a worse bug where a caller-supplied to was requir

Read the thread · 2026-08-14 · closed · 0 comments

email-mcp: derive the MCP tool list from EMAIL_ACTIONS (follow-up to #174, after server.ts mailbox rewrite merges)

Summary

Follow-up to #174 (fixed in #180). Now that EMAIL_ACTIONS in @usejunior/email-core is a populated canonical registry (28 actions), packages/email-mcp/src/server.ts should derive its core-backed MCP tools from it instead of the hand-maintained list of wrapAction(...) calls (~line 1058 onward), fulfilling the "Action to Tool Mapping" requirement in openspec/specs/mcp-transport/spec.md ("WHEN a new action is added to EMAIL_ACTIONS in email-core THEN it automatically appears

Read the thread · 2026-08-11 · open · 0 comments

LazyProviderState keeps two representations of "which mailboxes exist", bridged by a fallback that fabricates emailAddress from a display name

Summary

LazyProviderState (packages/email-mcp/src/server.ts:41-53) carries two representations of "which mailboxes exist":

Because the two can disagree, fallbackConnectedMailbox() (server.ts:406-420) exists to synthesize a plural entry from the singular fields whenever mailboxes[] is empty, and getKnownMailboxes() (server.ts:422-424) bridges every consumer

Read the thread · 2026-08-11 · closed · 0 comments

email-core: EMAIL_ACTIONS registry is permanently empty — public API exports a dead, always-[] array

Summary

packages/email-core/src/actions/registry.ts declares itself the "single source of truth for all email actions" (line 1), but nothing in the codebase ever calls registerAction() — so the EMAIL_ACTIONS array exported as public API from the published npm package @usejunior/email-core (0.1.11) is permanently empty at runtime, while the real tool list is hand-maintained in packages/email-mcp/src/server.ts.

Evidence (validated by an executed Codex peer review)

Read the thread · 2026-08-11 · closed · 0 comments

Action-layer retry wraps non-idempotent send operations: ambiguous failures can double-send, and Graph/Gmail errors bypass the retryable-error contract

Summary

withRetry (packages/email-core/src/providers/provider.ts:239) wraps the three delivery boundaries — send_email → provider.sendMessage (packages/email-core/src/actions/send.ts:231), reply_to_email → provider.replyToMessage (packages/email-core/src/actions/reply.ts:226), and send_draft → provider.sendDraft (packages/email-core/src/actions/draft.ts:313) — with { maxRetries: 3 } (4 total attempts). Its only non-retry escape hatch is `err instanceof ProviderError && !err

Read the thread · 2026-08-11 · closed · 0 comments

create_draft requires subject on the reply path, then never uses it — and forcing callers to invent one breaks Gmail threading

create_draft requires subject on the reply path, then never uses it — and forcing callers to invent one is exactly what breaks Gmail threading.

Summary

create_draft with reply_to set rejects the call unless subject is supplied:

MISSING_FIELD: subject is required — provide it as a parameter or in body_file frontmatter

But on the reply path the resolved subject is never passed to the provider. createReplyDraft() receives to, cc, bodyHtml, attachments and `r

Read the thread · 2026-08-11 · closed · 0 comments

feat(draft): opt-in update_source_frontmatter to write draft_id/draft_link back to the source body_file

Context

Re-cut from #25, which is being closed. Nearly all of that PR has since landed on main through other work — the attachment loader, reply_all, compose-helpers, the safe-path.ts path-traversal fix, and the P0 reply-all allowlist gate are all present. This back-link feature is the only piece that never landed.

Proposal

Add an opt-in update_source_frontmatter flag (default false) to create_draft / reply_to_email.

When the draft is created from a body_file, pat

Read the thread · 2026-08-06 · open · 0 comments

test(auth): cover the reconnect() fail-fast path for unconsented scopes

Problem

#168 fixed a bug where the MCP serve path could hang indefinitely: reconnect() omitted disableAutomaticAuthentication, so a token cache that could not satisfy the requested scopes made DeviceCodeCredential silently start an interactive device flow — blocking for the whole polling window and writing its prompt to stdout, which is the JSON-RPC channel on an stdio server.

The fix works and was verified live (fail-fast in 228ms vs. an indefinite hang). But codecov/patch fl

Read the thread · 2026-08-06 · open · 0 comments

Add sandboxed local-file materialization for downloaded attachments

Problem

download_attachment returns attachment bytes as a base64-backed MCP embedded resource. Clients that need to inspect a PDF, Office document, or image with local tooling have no supported way to materialize that resource as a file.

This forces clients into brittle workarounds such as copying large base64 payloads through a shell or terminal session. Besides being inefficient, those workarounds increase the risk of truncation, encoding errors, excessive logs, and accidental exposure

Read the thread · 2026-08-06 · open · 0 comments

create_draft requires to, then silently discards it on the reply path — the draft is addressed to whoever the provider picks

Summary

create_draft rejects the call if to is missing (MISSING_FIELD: to is required), and then, when reply_to is also set, never passes to to the provider. The caller-supplied To is validated, parsed, and dropped. The draft is addressed to whatever the provider derives from the parent message, with no error and no warning.

This is the same family of bug as #48 (createDraft() drops cc/bcc) and #102 (read_email drops cc) — a recipient field that silently doesn'

Read the thread · 2026-08-04 · closed · 0 comments

Graph scopes are hardcoded: no read-only / observe-only profile

Problem

provider-microsoft/src/auth.ts:14 and :16 define GRAPH_SCOPES and GRAPH_SCOPES_FULL as hardcoded module constants, and DelegatedAuthManager authenticates with the full list at :129. No env var, no config file, no flag — the only env override in that file is EMAIL_AGENT_MCP_HOME, for token storage.

So a tenant consents to Mail.Read, Mail.ReadWrite, Mail.Send, MailboxSettings.ReadWrite, User.Read, offline_access, or it does not connect. **There is no read-onl

Read the thread · 2026-07-30 · closed · 0 comments

The remaining reports are on the project's issue tracker.