[3mdistal]

Problem

Outside agents, such as Claude, ChatGPT or Cursor connected to Mail over Model Context Protocol (MCP), write emails with Mail's manage-draft action. Chat apps that support MCP Apps then embed the result in the conversation, so the person can check the draft and send it. Until now that embed was the whole Mail inbox with the compose window open, in a 900px-tall frame. Most of it went to the sidebar and message list, the draft sat in a corner, and at phone width it was barely usable.

Approach

The embed now points at a new /draft?id=… route that shows only what the person needs to review and send:

• A reply shows the conversation, then the editable draft. Older messages fold to one line each (sender, snippet, date), and the latest one is open. Beyond the last three, earlier messages fold behind an "Earlier messages (n)" button.
• A new email shows just the editable draft.

The draft is Mail's real composer, not a copy: recipients, Cc and Bcc, the From picker (when more than one account is connected), formatting, attachments, delete, Send and scheduling work as in the inbox, and edits save to the same draft. The host's "Open in Mail" button still opens the full inbox with this draft.

After Send, the card shows the usual undo window, then "Message sent." It also covers a scheduled send, a deleted draft, a failed send or delete, a missing draft and a thread that couldn't load. When the person sends, schedules or deletes, the card tells the chat's model, so the agent doesn't keep editing a draft that's gone. It reports only what really happened: a delete once the draft and its saved copy in Gmail are both gone, and nothing when the draft was edited while it was being scheduled. That edited draft stays open, with a toast saying the earlier version is scheduled. When an agent drafted a reply without naming its thread, Send and scheduling wait the moment it takes the card to look the thread up, so a scheduled reply lands in its conversation.

This pairs with #8005, which adds manage-draft to the tools Mail offers outside agents. This PR only changes what they see.

Screenshots

Rendered as an MCP App in MCPJam's ChatGPT emulator, from a production build with fake mail.

	Reply	New email
Light
Dark

At 380px, the width of Claude's phone app, the thread gives up more height so the draft stays readable:

Reply, light	Reply, dark	New, light	New, dark

Other states

Sent	Send failed	Thread couldn't load

Attachment (upload stubbed)	Deleted in the card

What changed

All in templates/mail:

• actions/manage-draft.ts: create and update return the /draft path as the embed, with the inbox link as deepLinkUrl for "Open in Mail". The frame height drops from 900 to 604.
• app/routes/draft.tsx and app/components/email/DraftCard.tsx: the new route and card. AppLayout renders /draft without the app shell, as it already does for /email. The inbox's toasts for a failed save or delete live in that shell, so the card shows them itself. A reply's draft gets a thread ID only when it already has one or Mail looks it up from the message it answers. Send and Send later wait for that lookup, and its first answer sticks, so a reply's thread can't change while it's being scheduled. When the lookup fails, the card may still try the message's own ID to show the conversation, but never puts that guess on the draft.
• ComposeModal.tsx: a presentation="card" mode, an onSendProgress callback and a sendDisabled prop. The card mode drops the window's title bar, autofocus and Escape-to-close, shows Cc and Bcc when the draft already has them, and hides the subject on replies. When a caller passes onSendProgress, it gets the send states and the send toasts are skipped. sendDisabled disables Send and Send later, including their keyboard shortcuts. If the draft changes while a schedule request is in flight, including a move to another thread, the edited draft stays open and the "Scheduled for…" toast shows in both modes.
• EmailThread.tsx exports the folded and open message rows for the card to reuse; their reply and forward buttons hide when no handler is passed. use-compose-state.ts exposes isError and refetch, so the card can tell a missing draft from one that couldn't load. Its discard now resolves to whether the draft and its saved copy in Gmail were both deleted; existing callers ignore the result.
• New mail.draftCard strings in all 11 locales, and a changelog entry.

Safety and operations

• Rollout: chat apps still show inline MCP Apps only where AGENT_NATIVE_MCP_APPS_INLINE (or its per-email allowlist) is on. Elsewhere, agents get the same text result and link as before. This PR adds no flag.
• Data and rollback: no schema, migration or permission change. The card uses the inbox's draft and thread endpoints and sends through the same POST /api/emails/send. Reverting the PR restores the full-inbox embed.
• Height: 604 is the 560px document that core allows an inline chat app (MCP_CHAT_BRIDGE_VIEWPORT_HEIGHT in packages/core/src/client/embed-auth.ts), plus the host bar's 44px. A shorter frame for new emails would need core to accept a height per embed, so both cases use 604 and the card fits itself to it.

Verification

• Automated: new DraftCard tests (16) cover the reply and new-email layouts, folding, every outcome state, the message to the model, a delete that doesn't stick, a failed save, a reply whose Send waits for its thread lookup, one whose lookup fails, and two connected accounts reaching the From picker. Five ComposeModal tests cover the card mode (send states replace toasts; copied Cc shows without a click; a draft edited while scheduling stays open; so does one moved to another thread; sendDisabled holds Send and scheduling), and manage-draft.spec.ts checks the embed path and deep link. The full Mail suite (1,941 tests), agent-native typecheck and all 93 pnpm guards pass at the current head.
• Real interface: before the review fixes, a local production build, rendered as an MCP App in MCPJam's ChatGPT and Cursor emulators at 864px and 380px, light and dark, signed in as a test account with fake mail.
  • Send showed Undo for about 10 seconds, then "Message sent." The message reached Sent, and the host received one model update, {draftId, status: "sent"}. Undo returned to the editable draft.
  • A forced send failure showed "Failed to send email" and kept the draft editable. A failing thread request showed its notice, kept the draft editable and requested the thread only once.
  • Deleting in the card showed "Draft deleted.", and a reload showed "Draft not found." That notice is now its title alone.
  • Edits survived a reload. Nothing takes focus on load, Tab reaches every control in order, Fullscreen fills the frame, and Open in Mail opens the inbox with this draft.
• Not verified:
  • Real Claude or ChatGPT. That needs a public HTTPS tunnel to a local server holding the test account's Gmail tokens, plus a chat account with custom connectors; neither was set up. MCPJam's Claude emulator refuses to frame the app (frame-src 'self'), so Claude's layout is inferred from the 380px render. Beta, once this and Expose Mail draft review to connected agents #8005 merge, is the first real-host check.
  • Two live accounts. The test workspace has one Google account; the unit test covers the From picker.
  • A real attachment upload. The local build has no file storage, so the card showed the composer's "not configured" toast; a stubbed upload showed the file chip with remove.
  • The review fixes in a browser. A delete that doesn't stick, a failed save, a draft edited while scheduling, Send waiting for a reply's thread lookup and a reply whose lookup fails are covered by unit tests only.
  • The scheduled state in a browser. Scheduling failed on an unrelated local database error, so only the unit test covers it. The schedule menu itself fits at 380×560.

Review focus

1. ComposeModal.tsx wraps the title bar in {!isCard && …}, so most of that file's diff is re-indentation. Hide whitespace to see the logic.
2. With onSendProgress, the send toasts are skipped and the card shows each state instead. Is there a path where a failure shows neither? The schedule-failure toast still shows in both modes on purpose, as does "Scheduled for…" when the draft was edited mid-schedule.
3. The 604 height depends on core's 560px limit. If core changes that number, this one has to follow.
4. Send stays disabled until a reply's thread lookup returns or fails. That's one request, retried once. If it hangs, the card can't send, though "Open in Mail" still can. Is that a fair price for keeping scheduled replies in their thread?
5. When the person sends, schedules or deletes, the card tells the model "The user sent email draft X from the Mail card." with {draftId, status}, and reports a delete only once it has stuck. Is that the right shape for agents to act on?

Follow-ups

• Per-embed heights in core, so a new email can get a shorter card. A later product decision.
• Host theme. Embeds follow Mail's theme or the operating system, not the chat app's. That's framework-wide, also a later decision.

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The changes affect Mail’s agent-draft card and the actions available inside it.

Restore draft save and delete warnings and satisfy the density rule before merging.

Findings

1.  Draft failures lose their warnings ▶
2.  Empty card breaks density rules ▶

Summary

Adds a compact /draft chat card using Mail’s existing composer.

• Agent-created drafts open in a compact card with their reply thread.
• Mail’s composer fits inside the draft card and reports what happens after Send.
• manage-draft opens the card while keeping a link to the full inbox.

Acknowledged choices from 3mdistal: reply subjects are intentionally hidden; shorter per-embed heights and host-theme support are deferred.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[manage-draft] --> B["/draft?id=…"]
  B --> C[DraftCard]
  C --> D[Conversation history]
  C --> E[ComposeModal card]
  E --> F[Existing save and delete hooks]
  F --> G[Failure events]
  G --> H[AppLayoutInner listeners skipped]
  E --> I[Send or schedule]
  I --> J[Card outcome]
  J --> K[Chat model update]

Loading

_{Reviews (1) · Last reviewed commit: "Test the Mail draft card's scheduled sta..." · Reviewed by Greptile}

[builder-io-integration]

Builder reviewed your changes and has a few items to flag 🟡

Review Details

Incremental review summary

I reviewed PR #8018 at 8a7a30da against the previous reviewed head 2869ba10. The update restores comparison of replyToThreadId so explicit retargets during scheduling remain open, and holds sending/scheduling while a reply's thread lookup is pending. I verified and resolved the prior explicit-thread-change finding. The pending-lookup safeguard addresses the normal in-flight case; the existing thread-ID finding remains open for cases where lookup settles as an error or cannot run, so I did not repost it.

This remains a standard-risk Mail lifecycle change. I found one additional low-severity issue: the lookup error is stored as a settled result for that key, so a later successful refetch is ignored and the draft never receives its resolved thread ID. Because the error state also clears lookupPending, send and schedule are enabled in that state. No further confirmed issues were found in the incremental diff.

🧪 Browser testing: Skipped — browser-test-planner is unavailable in this environment; PR touches UI code.

[steve8708]

Thanks for the update. The loading safeguard covers an in-flight lookup, but a lookup error is cached as a settled result; lookupPending then clears and Send/Schedule are re-enabled without a resolved reply thread ID, while later refetches are ignored. Please keep these actions disabled until a valid thread is resolved, or make an error retryable and test the recovery path.