[BUG] TUI renumbers the user's own ordered list when echoing it — every item after the first loses its typed number (regression in 2.1.234)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

[To be clear: human-hand-verified report of in-the-wild bug, generated using Claude Code CLI/Fable 5.1; this has a number of very similar reports, documented below, but this is distinct, and a regression]

When I submit a message containing an ordered list whose numbers are not already sequential, the TUI echoes my own message back with the numbers rewritten. Only the first item's number survives; every later item is replaced by first+1, first+2, and so on.

Typing this, as an answer to five numbered questions asked in the previous turn:

3. yes <redacted>
2. <redacted>
1. <redacted>
4. <redacted>
5. <redacted>

displays as 3. 4. 5. 6. 7. — so my answers to questions 2 and 1 appear as answers to questions 4 and 5, and my answers to 4 and 5 appear against numbers that were never asked.

Two things worth stating up front, because six earlier reports of this area were closed and I think this is why:

It is display-only now. The model receives the digits exactly as typed. I checked the session transcript JSONL for the real session this happened in (v2.1.261) and the raw message.content carries 3. / 2. / 1. / 4. / 5. verbatim. Earlier reports (#55753, #61463, #64288, #69768) all claimed the mutation reached the model. On current versions it does not. Anyone who checked the delivery path against those reports would have found nothing wrong.

The shape those reports used now renders correctly. A lone 2. is fine today; the list start index is already preserved. What is not preserved is every subsequent item's number. So re-testing from the older reports today gives "cannot reproduce", while the bug is very much alive in the multi-item case.

Measured on 2.1.263, same harness and message each time:

| Typed | Displayed | Verdict |
| --- | --- | --- |
| 2. | 2. | preserved — start is honoured |
| 1. 2. 3. | 1. 2. 3. | preserved — already sequential |
| 2. 5. | 2. 3. | renumbered |
| 3. 2. 1. | 3. 4. 5. | renumbered |
| 3. 2. 1. (blank lines between) | 3. 4. 5. | renumbered |
| 3) 2) 1) | 3) 4) 5) | renumbered |

That last row matters for anyone relying on the workaround suggested in #75199: on 2.1.263, N) is renumbered exactly like N., so it is no longer a way out. I have not bisected that one, but 2.1.246's entry — "Fixed markdown rendering being disabled for a whole message when its first 500 characters contained no markdown, and for +/N) lists and setext headings" — looks like the change that brought N) under the same renderer. The other suggested escape, 3\., does preserve the number but renders the backslash visibly, so it is not really a workaround either.

This is the user-message counterpart of #87790, which is open for the same renumbering applied to the agent's replies. Same renderer, same rule, both directions of the conversation.

What Should Happen?

The echoed message should show the numbers I typed. Answering a numbered question by its number is an ordinary thing to do in a conversation, and in that context the digits are content, not list presentation.

Note that preserving the ordered-list start attribute — the fix proposed in #51697 — is not sufficient, and appears to be what already ships: 3. 2. 1. still renders 3. 4. 5. with start preserved perfectly. The numbers after the first have to be kept individually, or bare N. at the start of a line in a user message has to stop being treated as list syntax at all.

Rendering my own prompt as markdown is a real improvement in general (code blocks and inline code especially). The narrow ask is that ordered-list numbering not be normalised away in it.

Error Messages/Logs

# Verbatim from the pty, after submitting the message
#   3. three / 2. two / 1. one / 4. four / 5. five
❯ 3. three
  4. two
  5. one
  6. four
  7. five


Same message on 2.1.233, unchanged harness:


❯ 3. three
  2. two
  1. one
  4. four
  5. five

Steps to Reproduce

No credentials needed — the renumbering happens when the message is echoed, before any request is made, so this reproduces on a machine that is not logged in at all.

1. Run claude --bare in any directory. (--bare only keeps hooks and project config out of it; plain claude behaves the same.)
2. Enter this as a single multi-line message — paste it, or use the newline key between lines:

```

1. three
2. two
3. one
4. four
5. five

```

1. Press Enter to submit.
2. Look at your own message as the TUI echoes it back above the input box.

Expected: 3. three / 2. two / 1. one / 4. four / 5. five
Actual: 3. three / 4. two / 5. one / 6. four / 7. five

To confirm the regression, the same steps under npx -y @anthropic-ai/claude-code@2.1.233 --bare show the numbers unchanged, and @2.1.234 shows them renumbered.

To confirm the model is unaffected, submit the list in a logged-in session and read the message.content of your own turn in ~/.claude/projects/<project>/<session>.jsonl — the typed digits are there.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.233

Claude Code Version

2.1.263

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

2.1.234's changelog entry looks like the cause: "Improved the transcript: your own prompts now render markdown (highlighted code blocks, inline code, lists) the same way replies do." That is the release in which the prompt echo acquired a markdown renderer at all, which fits what I measured either side of it. (The desktop app reports go back further, to v2.1.92 — I have only measured the terminal TUI.)

Additional Information

Debian 13 (trixie), x86_64, in a container; TERM=xterm-256color, 100×40.

The version comparison above was driven through a scripted pty rather than by hand, so that each version got a byte-identical message; the steps in "Steps to Reproduce" are the by-hand equivalent. One note for anyone else scripting it: the pre-submit input box holds the numbers as typed, so the evidence has to be read from after the submit keystroke, or the bug looks absent.

Prior reports of this area, all closed and locked, none of which reflect the display-only or the multi-item finding above: #51697, #55753, #61463, #64288, #69768, #75199. Open and closely related: #87790.

Drafted with Claude Code, then reproduced, checked and edited by me. I have run the reproduction steps myself, but not the version bisect or transcript check; I'll answer follow-ups here.