/ask and /btw answers go blank while the dialog stays open

[MikeKlebolt]

Describe the bug

When I use /ask or its /btw alias, answer text appears and then disappears without me pressing Escape or otherwise dismissing the response. The answer box stays open but becomes blank.

This is different from the expected disappearance after explicitly closing the temporary answer panel.

Affected version

1.0.83-5

Steps to reproduce the behavior

1. Run Copilot CLI in the VS Code integrated terminal on Windows.
2. In an existing conversation, submit /ask <a short text-only question> or /btw <a short text-only question>.
3. Allow the answer to render and leave the panel open without dismissing it.
4. Observe that the answer text can disappear while the panel remains open.

This has happened repeatedly in this environment, but a deterministic minimal reproduction has not yet been isolated. It is not established whether a resumed conversation or a concurrently running main task is required.

Expected behavior

Once answer text is displayed, it should remain readable in the open panel until I explicitly dismiss it. Finishing the response should not erase already displayed text.

Additional context

• OS/architecture: Windows, x64.
• Terminal: VS Code integrated terminal.
• Related closed report: /ask not showing model response on /resume chats. Just blank screen. See attachment. #3759 describes blank /ask responses on resumed chats in version 1.0.61. Linking as possibly related, not as a confirmed duplicate or regression.

Suspected cause, not confirmed: Completion handling may replace an already streamed answer with an empty value when the final answer payload is empty or missing. A component-level simulation reproduces that failure mode, but the final payload from an actual failing live query has not been captured.

Local workaround status: The symptom was observed before modifying the installation. A temporary local UI workaround was subsequently applied to retain displayed and buffered streamed text when the final answer is empty or missing, while still using a nonempty final answer when provided. Its effectiveness against the original live symptom has not yet been confirmed; it is not an upstream fix or proof of the suspected cause.

[MikeKlebolt]

Local workaround implementation details

The local change for CLI 1.0.83-5 targets one possible failure mode: a successful completion event replacing already streamed text with an empty or missing final answer.

The following is illustrative pseudocode for the completion handler, not a source-level patch or the bundled client code.

Before:

pendingText = "";
setAnswer(finalAnswer ?? "");

Local workaround:

const pending = pendingText;
pendingText = "";
setAnswer(displayedText => finalAnswer || displayedText + pending);

Capturing the pending buffer before clearing it preserves the last unflushed chunks. The functional state update uses the latest displayed text, including previously queued chunk updates. A nonempty final answer remains authoritative, so it is not concatenated with the streamed text or duplicated.

This change is confined to successful completion handling; explicit dismissal and the existing failure path are unchanged.

Evidence boundary: The empty/missing-final-answer failure mode was reproduced in a component-level simulation, including buffered chunks and batched state updates. A failing live query's final payload has not been captured, and the workaround has not yet been confirmed against the original live symptom. Please treat this as a proposed defensive rendering change, not a confirmed root cause or upstream fix.