Describe the bug
The chat composer normalizes/collapses leading whitespace on user-submitted messages. Any indentation the user enters at the start of a line — whether typed as multiple spaces or pasted from an external editor — is reduced to a single space by the time the message is processed. Because Markdown list nesting depends entirely on leading indentation (>=2 spaces), users cannot author nested/sub-item lists from the composer; all sub-items collapse to the top level.
Steps to reproduce
- In the chat composer, type a nested list:
- top1
- sub1-1
- sub1-2
- top2
- Send the message.
- Observe the received/rendered content has only a single leading space before each sub-item, so
sub1-1/sub1-2 render at the same level as top1.
Reproduced with: multi-space typing, 3-space typing, and copy/paste from an external editor — all collapse to 1 leading space.
Expected behavior
Leading whitespace entered by the user should be preserved (or at least >=2 spaces retained) so standard Markdown nested lists render with correct hierarchy.
Actual behavior
All leading indentation is collapsed to a single space; nested list items are flattened to the top level.
Workarounds attempted (all fail or are impractical)
- Typing 2 or 3 leading spaces -> collapsed to 1.
- Pasting pre-indented Markdown -> collapsed to 1.
- Pressing Tab to indent -> moves focus to the next UI control (cannot insert indentation).
- Only partial workaround: using
entities or faux-hierarchy (bold headers + arrow prefixes).
Environment
- GitHub Copilot CLI / desktop chat: (version not specified)
- OS: Windows
- Model: Claude Opus 4.8
Additional context
Affects both - and * bullet styles. The same Markdown renders correctly on GitHub.com and in standard Markdown editors, confirming the issue is input-side whitespace normalization in the composer, not the Markdown itself.
Describe the bug
The chat composer normalizes/collapses leading whitespace on user-submitted messages. Any indentation the user enters at the start of a line — whether typed as multiple spaces or pasted from an external editor — is reduced to a single space by the time the message is processed. Because Markdown list nesting depends entirely on leading indentation (>=2 spaces), users cannot author nested/sub-item lists from the composer; all sub-items collapse to the top level.
Steps to reproduce
sub1-1/sub1-2render at the same level astop1.Reproduced with: multi-space typing, 3-space typing, and copy/paste from an external editor — all collapse to 1 leading space.
Expected behavior
Leading whitespace entered by the user should be preserved (or at least >=2 spaces retained) so standard Markdown nested lists render with correct hierarchy.
Actual behavior
All leading indentation is collapsed to a single space; nested list items are flattened to the top level.
Workarounds attempted (all fail or are impractical)
entities or faux-hierarchy (bold headers + arrow prefixes).Environment
Additional context
Affects both
-and*bullet styles. The same Markdown renders correctly on GitHub.com and in standard Markdown editors, confirming the issue is input-side whitespace normalization in the composer, not the Markdown itself.