Ordered-list markdown in submitted messages gets auto-renumbered (e.g. '2.'/'5.' → '1.'/'2.'), clobbering intended numbering

Resolved 💬 1 comment Opened May 31, 2026 by viviane1016 Closed Jul 3, 2026

Summary

When a user message contains a markdown ordered list with non-sequential or intentionally-specific numbering (e.g. items labelled 2. and 5. to refer back to a prior enumerated list), the rendered/submitted message re-numbers them sequentially (1., 2., …). The original numbering is preserved in the editor but rewritten after send. The user cannot assert "I really do mean 2. and 5." through to the rendered transcript.

Repro

  1. In the input editor, type a list using deliberate numbers, e.g.:

```

  1. (responding to your point 2)
  2. (responding to your point 5)

```

  1. Confirm it looks right in the editor.
  2. Send.
  3. Expected: the message renders with 2. and 5. as typed.
  4. Actual: the renderer normalizes to 1., 2. — the intended cross-reference numbering is lost.

Why it bites (not purely cosmetic)

In long technical back-and-forths, both sides use numbered lists to track threads ("addressing your 2 and 5"). Auto-renumbering silently breaks that correspondence — the recipient (human or model) can no longer tell which prior point each item answers. It got noticeably worse in one long session after an auto-archive event, where the numbering correspondence between turns desynced entirely.

Workaround the user found

Lettered lists (a., b., c.) appear not to be auto-renumbered the same way — so switching ordered→lettered preserves intent. Mentioned in case it narrows the cause (ordered-list normalization specifically).

Severity

Niggle / quality-of-life. Not blocking, but a recurring papercut in numbered-point discussions. Filed at a user's request ("for giggles") after it tripped a long design conversation.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗