[prudenciooficial]

Summary

Adds Reply with AI: the user says in a few words what the reply should say ("approve the artwork and ask for the print date") and the AI writes it from the conversation so far. The existing compose AI actions draft from the subject and recipients, or rewrite what is already typed; none of them reads the message being answered. Agreed in #652.

It is offered where a reply starts: a Reply with AI button in the reading pane toolbar, one on each open message in the conversation view, and an entry in the composer's AI menu when replying, in place of Write draft. The composer opens with the instruction field focused. The suggestion streams into the existing AI panel with Apply and Dismiss, and the instruction stays editable to ask again in other words.

Reading pane	The suggestion, from the instruction and the thread

Conversation view

When it is offered. It writes a draft (the writing assistant) from received mail (which only summaries send to the provider), so it needs both switches on, and the rich-text composer, since the plain-text one has no AI panel. The reading pane, the conversation view and the composer's menu all check the same thing; where it is not offered, a reply's menu keeps Write draft. The server enforces it too: the request uses a new reply purpose, which /api/ai/chat refuses unless both switches are on.

Changes

• utils/aiReply.js (new) builds the request:
  • The thread up to the message being answered, the newest 10, one copy of each, drafts left out, the user's own messages marked. A reply opened from the ungrouped list carries no thread_id, so the thread is found through resolve-message from the answered Message-ID. A message with no thread is read on its own, and if nothing loads, the quoted original the composer already holds is used.
  • Each message is read with aiMessageText(body, { subject }) (fix(ai): send actions the visible message, not CSS and quoted history (#646) #647), as the AI actions read it.
  • It stays under the proxy's 32,000-character limit: messages go whole, newest first, and older ones are left out when the rest does not fit. Only the message being answered can be cut, when it is too long by itself, at a paragraph or sentence break. The model is told what was left out or cut, and the panel says so: "too long to send", or "the latest 10 messages" when only the cap left some out.
  • Each email sits between <<<EMAIL <token> …>>> and <<<END <token>>> lines, with a token drawn for each request. Who wrote it, which one is answered and where it was cut are said on that line, and the model is told that only lines carrying the token are markers, so a received body cannot pass for another email, the user, or an instruction. The user's instruction is a message of its own, the only one to follow. The prompt also asks for the conversation's language, a bracketed placeholder instead of an invented fact, and leaves the signature to the composer (or signs with the sender's name when it is off, feat: add a compose signature toggle and mailbox default #556).
• backend/src/services/aiAccess.js, routes/ai.js: the reply purpose, which needs both switches. A refusal names the switch that is off, and api.ai.chat passes it on, so the panel says "summaries are off" or "the writing assistant is off" as it is.
• ComposeModal.jsx: the action and ComposeAiPanel, one component for the phone and desktop layouts. The conversation is loaded once per composer, so rewording only asks the AI again. The panel's status lines are a live region and its error an alert.
• MessagePane.jsx, ConversationMessageCard.jsx, ConversationPane.jsx, composeFromMessage.js: the buttons, which follow the user's reply default, and an aiReply flag that opens the composer with the panel. A message reopened by Undo send drops the flag.
• The 7 new strings in all 11 locales.

Apply already keeps model output as text and keeps blank lines between paragraphs, from #651.

Testing

• Unit tests for building the request (aiReply.test.js), including a received body with forged markers, a forged "(the user)" line and an instruction line, which stay text inside that email. Render tests: the reply is written from the thread and the instruction, under the reply purpose; Apply keeps the quoted original; rewording does not reload the thread; markup in a suggestion stays text; with summaries off a reply's menu offers Write draft; each refusal names its switch; the cap and the too-long notices; the button opens the composer with the instruction focused and follows the reply default; it is not offered in plain-text mode; Undo does not reopen the panel. Backend tests for the reply purpose with each switch off. The new tests were checked to fail with their fix reverted.
• Frontend lint and build pass, and the frontend suite apart from one InboxReplyDraftObserver test that fails on main in my environment too. The backend suite and both lints pass. The screenshots are from an earlier revision, checked in Chromium (desktop and phone width) against a throwaway stack with GreenMail and a stub OpenAI-compatible provider (fictitious data).

---

Contributor License Agreement

By submitting this pull request I confirm that:

• I have read and agree to the Contributor License Agreement.
• My contribution is my own original work (or I have identified any
  third-party material and confirmed it is compatible with the CLA).
• I have the right to submit this contribution under the terms of the CLA.

My English is basic, so this description was written with help from Claude.

🤖 Generated with the help of Claude Code

[maathimself]

Thanks for the work on this. I'm not going to merge it as it stands: it's a new feature that sends received mail to the AI provider, and per CONTRIBUTING a feature like this needs an issue first so we can agree on the direction. It also isn't on the plan for 4.1 (scheduled send, sorting and pinned emails, the full-width list and category totals).

If you'd like to pursue it, please open an issue describing it. A few things would need to change for it to land later:

• It's gated on the compose feature, which admins know as "draft & improve emails" and which until now only sent the user's own draft. Reading the thread sends up to ten received messages, a different privacy scope, so it needs its own setting (or at least the summarize one).
• htmlToText and stripQuotedReply are quadratic on crafted input: 320 KB of <div in one message blocks the tab for about 20 s once the button is clicked. Anything run over email HTML has to stay linear on hostile input.
• Messages are cut at 12k/6k characters without telling the model or the user. Since Summarize and custom AI actions silently omit email text after 6000 characters #633 the rule is the whole email up to 32k, with any cut disclosed.

Two parts are useful on their own: escaping the suggestion when it's applied, and keeping blank lines between paragraphs. If you split those into a small PR, I'll review it separately. I'm leaving this one open for now.

[prudenciooficial]

Thank you for the review and the clear direction.

• I opened Reply with AI: draft a reply from the conversation and an instruction #652 to agree on the direction first, with your three points: its own setting for reading the thread, the whole thread up to 32k with any cut disclosed, and the parsing.
• The parsing is already fixed here (2b8b911). The HTML is read by a scanner, and quote headers are matched by how the line starts and ends. Your 320 KB <div case and a long German header now take milliseconds; the tests added for them fail on the old code (about 50 s and 9 s).
• The two parts you mentioned are in fix(compose): Apply keeps a suggestion's blank lines, and its markup as text #651, on their own.

I'll leave this PR as it is until we agree on the issue.

My English is basic, so this reply was written with the help of Claude (Claude Code).

[prudenciooficial]

An update on the three points from your review, while #652 waits for your view:

• Privacy scope: since Feature Request: Per-user AI Assistant permissions #644, Reply with AI asks under summaries, since it sends received mail, and is offered only when both the writing assistant and summaries are on. Whether it should have a setting of its own is the open question in Reply with AI: draft a reply from the conversation and an instruction #652.
• Linear on hostile input: done in 2b8b911.
• The whole conversation, with any cut disclosed: done in 2aef458. The conversation goes whole up to the 32,000-character request. When it does not fit, the oldest messages are left out first, and a message being answered that is too long by itself is cut at a paragraph or sentence break with cutPoint (now exported from aiActions.js). The model is told what was left out, and the panel says the suggestion is based on the latest part of the conversation.

My English is basic, so this reply was written with the help of Claude (Claude Code).

[maathimself]

Reviewed 4b9355c merged onto v4.0.5: it merges cleanly, the full suites pass, and in Chromium, Firefox and WebKit the flow works on desktop and phone. Privacy holds on the server (with summaries off, no received mail reaches the provider), Apply keeps model output as text, and the result only ever lands in the user's draft. Thread selection is scoped to the user's own accounts, drafts are left out, and the ten-message cap works as agreed in #652.

Changes needed:

1. Composer menu ignores the summaries setting. ComposeModal.jsx passes aiReplyEnabled={isReply} in both toolbars (~1896 and ~2496). With the writing assistant on and summaries off, a reply's AI menu offers Reply with AI and hides Write draft; the server then refuses the request. Use isReply && aiReplyAvailable(aiStatus, plaintextEmail) as the reading pane and conversation view already do, and keep Write draft when Reply with AI isn't available.
2. Wrong refusal message. ai_feature_disabled is mapped to compose.toolbar.aiFeatureOff ("the AI writing assistant off") even though Reply with AI is requested under summaries. The server sends feature, but utils/api.js builds the error with only status and code, so either pass feature through there or branch on the reply action, and use message.aiFeatureOff for summaries.
3. Use the shared extraction. aiReply.js has its own htmlToText and stripQuotedReply next to aiMessageText from fix(ai): send actions the visible message, not CSS and quoted history (#646) #647, and on real (sanitized) mail it loses content the shared one keeps: a note that quotes someone mid-text ("On the call, Anna wrote: …"), Gmail and Outlook forwards, "From: Berlin / Date: 3 May" style notices, prose ending in "schrieb:", and Apple inline answers below the "On … wrote:" line. Its closingTagAt is also quadratic on an unclosed <style>, <head> or <script> (300 KB: 6 to 17 s in Node, up to 32 s in WebKit). The sanitizer keeps those inputs out today, so this is defense in depth, but the comment at the top of the file says linear and it isn't. Please build each message with aiMessageText(body, { subject }) and drop the second pipeline.
4. Unforgeable markers. A received body containing --- Message 2 of 2 (the one being answered) ---, From: … (the user) or Instruction for the reply: lines appears in the built prompt exactly like the real ones. Please wrap each message in a per-request random marker (or neutralize lines that start with those markers), put the user's instruction in its own message as the only instruction, and add a test that a body can't create a second answered marker or instruction line.
5. Server-side gate. Reply with AI is requested as summarize, so "writing assistant and summaries both on" is only enforced in the client. Please add a reply purpose in aiAccess.js that requires both switches, with a test.

Also, please keep this PR to Reply with AI: Write draft now asks for an instruction and targets 120 to 220 words, which goes beyond what #652 agreed; a separate PR is welcome for that. And the PR description needs updating: the gating it describes has changed, escaping and blank lines on Apply landed in #651, and older messages are left out rather than shortened (only the message being answered can be cut).

Small: the partial notice says "too long to send" even when the ten-message cap left messages out; the conversation card always opens a plain reply while the reading pane uses the user's reply default; and the panel's status and error lines could use aria-live.

[prudenciooficial]

Thanks for the thorough review. All of it is addressed in c4e17d0 and 10957e8, with main merged in:

1. Composer menu: both toolbars get isReply && aiReplyAvailable(aiStatus, plaintextEmail), so with summaries off a reply's menu keeps Write draft.
2. Refusal message: api.ai.chat now keeps the server's feature. A refused reply shows message.aiFeatureOff when summaries are off and compose.toolbar.aiFeatureOff when the writing assistant is.
3. Shared extraction: each message is built with aiMessageText(body, { subject }), and so is the fallback from the quoted original. htmlToText and stripQuotedReply are gone, and the quadratic closingTagAt with them.
4. Unforgeable markers: each email sits between <<<EMAIL <token> …>>> and <<<END <token>>> lines.
   • The token is 96 bits, drawn per request, and drawn again if a body happens to contain it.
   • Who wrote the email, which one is answered and where it was cut are said on that marker line. The system prompt says only lines carrying the token are markers.
   • The instruction is a user message of its own, the only one to follow.
   • A test sends a body with the old markers, a forged (the user) From line, a fake token marker and an Instruction for the reply: line. It checks that there is exactly one answered marker, that those lines stay inside that email, and that there is one instruction.
5. Server-side gate: aiAccess.js has AI_PURPOSES with reply: ['compose', 'summarize']. /api/ai/chat refuses reply unless both switches are on, and names the one that is off. There are tests for each switch.

Write draft is back to main's behaviour. I'll open the instruction and the longer draft as a separate PR once this one settles, since it builds on the panel here. The description is updated.

Small ones:

• When only the ten-message cap left messages out, the panel now says "Based on the latest 10 messages of the conversation: older ones were left out", not the too-long note.
• The conversation card follows the reply default.
• The panel's status lines are in a role="status" live region, and the error is role="alert".

Something to check: the request now has two user messages in a row. OpenAI-compatible APIs and the Codex Responses API accept that, but some self-hosted chat templates require the roles to alternate (Mistral's on vLLM, for example). If you would rather keep a single user message, I can put the instruction after the conversation in the same message, outside the markers.

Tests: each new test was checked to fail with its fix reverted.

• Backend: the suite and both lints pass.
• Frontend: lint and build pass. The suite passes apart from one InboxReplyDraftObserver test, "explicit opening reports cancellation…", which fails on main in my environment too.
• I did not repeat the browser check on this revision.

My English is basic, so this reply was written with the help of Claude (Claude Code).

[maathimself]

Reviewed 48aa8bc merged onto 4.1.0. All five changes and the small ones are in, each new test fails with its fix reverted, the full suites pass, and in Chromium, Firefox and WebKit the flow works on desktop and phone, including Send later on a reply written with AI. With summaries off, no received mail reaches the provider. The InboxReplyDraftObserver test passes here, so that failure is specific to your environment.

On the two user messages: keep them. Every AI request already starts with two system messages in a row, so a template that requires alternating roles already fails on the existing actions. If that needs fixing, it belongs in the server for every action, not in this PR.

One small thing for later, not needed here: the subject line sits outside the markers, so it could move into the answered email's marker line.

Merging now, thanks. This ships in the next release. You mentioned a separate PR for Write draft with an instruction; it's welcome, please link #652 in it.

[maathimself]

Approved: re-reviewed and tested, see the comment above.