Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [Bug] Ordered list start index not preserved in user messages [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#51697•Fetched 2026-04-22 07:55:17
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
endofcakeendofcake
Participants
endofcakeendofcake
Timeline (top)
labeled ×4closed ×1

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.

Root Cause

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.

Code Example

[]
RAW_BUFFERClick to expand / collapse

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.:

    5. Agree, let's do this.
6. Does this need to be codified?

  3. User submits.

  4. 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

[]

extent analysis

TL;DR

Preserve the start attribute on <ol> when rendering user markdown to maintain the original list indices.

Guidance

  • Verify that the markdown parser is correctly handling the start attribute by checking the rendered HTML output for the presence of <ol start="X"> where X is the original list index.
  • Check the CSS and JavaScript code for any overrides that might be resetting the list index to 1, and modify or remove them as necessary.
  • Consider rendering user input as verbatim/monospace to preserve the original numbers, as an alternative solution.
  • Review the CommonMark specification to ensure that the implementation is correctly handling ordered lists with custom start indices.

Example

No code snippet is provided as the issue does not contain sufficient information about the implementation details.

Notes

The suggested fix assumes that the markdown parser is correctly handling the start attribute, and that the issue is due to an override in the CSS or JavaScript code. If this is not the case, further investigation may be necessary to identify the root cause.

Recommendation

Apply the workaround of preserving the start attribute on <ol> when rendering user markdown, as this is the most straightforward solution to maintain the original list indices.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [Bug] Ordered list start index not preserved in user messages [1 participants]