[BUG] User-typed ordered-list start index (e.g. `2.`) silently rewritten to `1.` before submission (re-file of #51697)

Summary

The Claude Code input renderer rewrites the start index of ordered lists in user messages. A user typing 2. tracked is right to select option 2 from a previously numbered set has their message rewritten to 1. tracked is right before the model ever sees it. The model then acts on the wrong option.

This was previously reported as #51697 by @endofcake on 2026-04-21 and closed NOT_PLANNED within one minute. The lock note on that issue instructs anyone hitting it again to file a new one — so here it is.

Environment

• Claude Code desktop app (macOS)
• Today: 2026-05-22

Repro from a live session today

1. Claude offered two choices and labeled them 1. and 2.:

> 1. File a higher-level decision ticket ...
> 2. decide now (tracked is right, local is wrong) ...

1. User typed 2. tracked is right. and hit enter.
2. The prompt reaching the model was 1. tracked is right. — the leading 2. was rewritten to 1..
3. The model responded as if path 1 had been chosen, started filing the higher-level decision ticket, and the user had to interrupt with [Request interrupted by user] Two: tracked is right to undo the misread.

Impact

• Numbered-choice flows are unreliable. The model can't distinguish "user picked 2" from "user picked 1" when the user uses the natural 2. syntax.
• Workarounds (escape the period, lead with the answer, use Two:) push the cost of the bug onto the user.
• Multi-turn agentic sessions become especially expensive when the model takes irreversible actions based on a misread option — files tickets, opens PRs, closes work.

Expected behavior

User-typed 2. at the start of a line stays 2. when delivered to the model. Markdown ordered-list rendering may renumber for display, but the value submitted to the model should preserve the typed start index.

Why "NOT_PLANNED" is the wrong resolution

This isn't a cosmetic markdown rendering glitch. It silently mutates user input between typing and model receipt. That's a correctness bug in a tool whose value depends on accurately conveying user intent to the model. Closing as NOT_PLANNED leaves a known input-mutation bug in production indefinitely.

Prior art

• #51697 (closed NOT_PLANNED, locked) — same bug, different user