Multiple-choice question UI cuts off characters on line-wrap boundary for multi-line answers

[dfrysinger]

Summary

When responding to an ask_user (multiple-choice) prompt with a freeform answer long enough to wrap to a second visual line, the input field drops characters and renders glitched separator artifacts at the right edge.

Reproduced live 2026-06-24 in Copilot CLI v1.0.64-3 on macOS.

Observed visible artifacts (from screenshot)

Input typed: This is what happens when a user types a multi line response, the cursor gets stuck to the edge of the screen and cant be moved by the arrows or mouse and the right edge glitches a bit.

Rendered by CLI:

>5.   his is what happens when a user types a multi line response, |he ||
      cursor gets stuck to the edge of the screen and cant be moved by
      the arrows or mouse and the right edge glitches a bit.

1. Leading character dropped — the leading T in This is missing; text starts at his is what.
2. Character at wrap boundary dropped — the cursor became he cursor (the t was eaten at the soft-wrap point between line 1 and line 2).
3. Right-edge glitches — stray | and || characters render at the cursor / wrap-boundary position, overlapping the choice-box border.
4. Cursor pins to right edge — once the input wraps, the cursor cannot be moved with arrow keys or mouse clicks to reposition within the typed text.

Expected

• All typed characters preserved (no leading clip, no wrap-boundary clip).
• Right edge renders cleanly without stray pipe characters.
• Cursor remains controllable via arrows / mouse across wrapped lines.

Note on original report

This was filed thinking the bug was about choice label wrap clipping. The actual bug is in the freeform response input field — the choice labels render fine.

Related

• ask_user User input formatting issues #3722 — ask_user user-input formatting issues (general; this may be a specific subset)
• Preserve question_tool rendered output (description/question/choices) when user presses Escape to dismiss #2732 — preserve question_tool rendered output on Esc

Why this matters

Silent character drops can change the meaning of the user's response (and the agent acts on what was received, not what was typed). Stuck cursor means the user can't fix it after the fact.

[examon]

This has been fixed in v1.0.65. The ask_user freeform answer option now wraps text across lines and keeps the cursor aligned, which resolves the dropped characters and stray pipe glyphs you saw when a typed answer wrapped to a second line. The version you reported on, v1.0.64-3, was a pre-release that predates the fix. If you still see this on v1.0.65, please comment with details and we'll take another look.