Windows desktop: long inline code responses repeatedly appear cut off mid-string, including after composer returns to Send

What version of the Codex App are you using (From “About Codex” dialog)?

Not yet collected. This report is based on repeated user observations and screenshots from the Windows desktop app, submitted by the assistant at the user's explicit request.

What subscription do you have?

Not collected.

What platform is your computer?

Windows. Exact OS build and app build have not been collected.
The visible model selector shows GPT-6 Astra with High reasoning. The interface language is Chinese.
Observed on 2026-09-19 (Asia/Shanghai).

What issue are you seeing?

Long inline VB.NET code responses repeatedly appear to stop early in the response, in the middle of a string literal. The user cannot obtain the complete copyable answer and has repeatedly asked the assistant to resend it.

Observed screenshot states:

• An earlier screenshot shows an incomplete string inside the first error-message helper, while the composer still shows the square Stop control.
• Later screenshots show the same kind of incomplete string near the beginning of the code output, but the composer already shows the upward-arrow Send control and accepts typed text.
• No explanatory error banner or explicit truncation notice is visible in the supplied screenshots.

The latest screenshot ends partway through an English CSV-format error message inside an ElseIf branch. Many subsequent classes and examples requested by the user are not visible.

The assistant-visible follow-up conversation context includes completed versions of those responses, including later classes, examples and an explicit final end marker. That is context-level evidence only: persisted transcript contents, transport events and the native renderer have NOT been inspected. It may be a display/history-delivery mismatch, but the root cause is unconfirmed. A clipped or independently scrollable code-block container has also not been ruled out.

What steps can reproduce the bug?

Observed sequence in an existing, long conversation; not an independently verified minimal reproduction:

1. In the Windows desktop app, request a complete multi-class VB.NET utility with detailed Chinese comments and bilingual strings, pasted directly into chat instead of delivered as a file.
2. The assistant produces a long fenced-code response.
3. The user reports that the output stops within the first helper class and supplies a screenshot showing a string ending mid-line.
4. Request the entire response again. The user reports the same problem.
5. Request the response organized into four labeled sections. The assistant emits the sections as separate code blocks within ONE long response; the same early cutoff is reported again. This did not test delivery across separate shorter turns.
6. In a later screenshot, the Send control is available despite the visibly incomplete code.

Original business code, local file paths, full conversation and screenshots are intentionally not attached. The screenshots were inspected by the reporting assistant; only the relevant UI observations are transcribed here.

What is the expected behavior?

The complete generated response should be viewable and copyable. If generation or delivery fails, the app should display an actionable error or an explicit incomplete-response state.

If code blocks have a size or scrolling limit, the remaining content and how to access it should be apparent; a turn should not appear successfully delivered while the user can only see an unfinished string.

Additional information

Impact: repeated retries have not delivered the complete inline source to the user.

Please investigate whether this is related to streaming delivery, final-message replacement, history projection, code-block clipping/virtualization, or another renderer issue. None of these is asserted as the root cause, and this report does not establish a service-wide outage.

No restart, cache reset, fresh-thread comparison, model comparison, or raw transcript/log inspection has been performed for this report. No credentials, private project files or complete session logs are included.

Start by reproducing the Windows desktop behavior with a long fenced-code response and compare the visible and copyable content with the persisted transcript. Inspect the mentioned streaming delivery, final-message replacement, history projection, and code-block rendering paths; done means the full response is accessible, or an actionable incomplete-response state is shown.