[Bug] Ordered list start index not preserved in user messages

Bug Description

Summary

User-submitted ordered lists are re-rendered starting at 1 regardless of the numbers typed in the source markdown. This breaks reference-by-number when users and Claude are co-referencing items from a previously-numbered list.

Environment

• Claude Code desktop app (macOS)
• Version: Claude 1.3561.0 (fbc74b) 2026-04-20T14:59:51.000Z

Repro

1. Claude sends a reply containing a numbered list with items 1 through 6.
2. User types a response that uses the same indices to address specific items, e.g.:

1. Agree, let's do this.
2. Does this need to be codified?

1. User submits.
2. The rendered user message shows these as 1. and 2., losing the original indices.

Expected

One of:

• (a) Preserve the start-index of the ordered list. CommonMark already supports this — 5. foo\n6. bar renders as <ol start="5">. HTML's native start attribute handles it without any custom logic.
• (b) Render user input as verbatim/monospace so numbers survive literally.

Actual

All ordered lists in user messages are renormalised to start at 1 and increment sequentially — suggesting the renderer is using a CSS counter or a JS-level markdown transform that overrides the parser's start value rather than passing it through.

Impact

When users and Claude are collaborating on a numbered structure (Claude proposes N options, user responds selectively by number), number-stability is load-bearing. Without it, Claude can't tell which items the user addressed and has to ask — a wasted round-trip. Noticed unprompted in a real collaboration session on 2026-04-22.

Suggested fix

Preserve the start attribute on <ol> when rendering user markdown. Pass the first list item's number through instead of implicitly defaulting to 1.

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.92
• Feedback ID: 92a7c3b5-b523-4930-ac5b-ba30c45dc774

Errors

[]