›_ Codex Issues
Codex Issues / #34167

Outlook Email drafts collapse plain-text paragraphs while the connector accepts undocumented HTML

Open 💬 0 comments Opened Jul 19, 2026 by MWals

Codex App version

0.144.5 (from the affected Codex Desktop session metadata)

Subscription

Organization workspace; the exact subscription name is not exposed to the Codex runtime.

Platform

Darwin 25.5.0 arm64 arm

What issue are you seeing?

The standard Outlook Email connector exposes:

  • draft_email(text_content), where text_content is described as plain text
  • create_reply_draft(comment), where comment has no content-type control

Following that contract and using LF or CRLF paragraph breaks produces Outlook drafts whose authored content is collapsed into one dense block without readable paragraph or list separation.

The connector nevertheless accepts semantic HTML fragments in those same fields. Passing <p>, <ul>/<ol>, and <li> produces correctly structured saved drafts. This behavior is reliable in practice but undocumented and contradicts the current Outlook plugin guidance that says writes are plain-text-only.

There is a second inconsistency:

  • draft_email can return body.contentType: "text" immediately after creation.
  • Fetching the exact same returned draft ID with fetch_message can then return a saved HTML body with the submitted <p>/<ul>/<li> structure.
  • Reply drafts often report contentType: "html" even when the newly authored plain-text prefix is collapsed, because the quoted thread itself is HTML.
  • bodyPreview can contain apparent line breaks that do not prove the full saved body is formatted.

This causes agents to create malformed drafts, retry several times, create duplicates, or fall back to browser automation to repair formatting.

What steps can reproduce the bug?

Use the signed-in standard Outlook Email connector. Do not send any message.

New draft: documented/plain-text path

{
  "to": [{"email": "recipient@example.com", "name": "Recipient"}],
  "subject": "Formatting reproduction",
  "text_content": "Hello,\n\nFirst paragraph.\n\n- Item one\n- Item two\n\nFinal sentence."
}
  1. Call draft_email.
  2. Capture the returned draft ID.
  3. Call fetch_message for that exact ID.
  4. Open the saved draft in Outlook.
  5. Observe that authored paragraphs/list items can be collapsed into a dense block.

CRLF (\r\n) instead of LF does not fix the issue.

New draft: currently undocumented working path

{
  "to": [{"email": "recipient@example.com", "name": "Recipient"}],
  "subject": "Formatting reproduction",
  "text_content": "<p>Hello,</p><p>First paragraph.</p><ul><li>Item one</li><li>Item two</li></ul><p>Final sentence.</p>"
}

Repeat the same create-and-fetch sequence. The saved draft retains paragraph and list structure.

The same A/B result occurs for replies when the source is passed through comment.

We reviewed 23 unique standard-connector draft IDs: 14 new drafts and 9 reply drafts. LF/CRLF-only inputs repeatedly produced the collapse, including at least three explicit user-visible failures. Semantic paragraph/list fragments produced structured readbacks for the tested new draft and six reply drafts.

What is the expected behavior?

One stable, documented contract:

  1. Preferably expose a structured body with explicit content and contentType fields for new, reply, and forward drafts.
  2. Alternatively, officially document that text_content and comment accept semantic HTML fragments and update the bundled Outlook skills accordingly.
  3. Preserve plain-text paragraph/list boundaries if the API continues to call these fields plain text.
  4. Make the create response and same-ID fetch_message representation consistent, or document that saved-body readback is mandatory.
  5. Do not present bodyPreview or contentType alone as formatting verification.

Additional information

No emails were sent. Testing and verification used unsent drafts only.

View original on GitHub ↗