Ordered-list markdown in submitted messages gets auto-renumbered (e.g. '2.'/'5.' → '1.'/'2.'), clobbering intended numbering
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
- In the input editor, type a list using deliberate numbers, e.g.:
```
- (responding to your point 2)
- (responding to your point 5)
```
- Confirm it looks right in the editor.
- Send.
- Expected: the message renders with
2.and5.as typed. - 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.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗