Draft-like text appears in final_answer across multiple Codex app-server turns

Environment

Windows, using Codex app-server through a custom WeChat bridge.
Current running app-server executable verified locally: codex-cli 0.153.4. The exact runtime version for each historical sample has not been established; the current version is not assumed for all samples.
All five observed turns record model gpt-5.6-sol and reasoning effort xhigh.

Observed behavior

Five independent turns contain unexpected draft-like text in otherwise user-facing replies. Minimal examples: "Need use Chinese" and "Wait avoid glitch".
For each sample:

• The persisted assistant response item has type message, content type output_text, and phase final_answer. No channel field is present.
• response_item, agent_message, and task_complete final text match by locally checked hashes.
• Text recorded after successful downstream delivery matches the canonical final text apart from leading/trailing whitespace.
  The issue was observed both before and after an app-server restart. Some samples predate the known persisted developer model-switch records, so those later switch records cannot explain all samples.

Local history-path audit

The custom bridge does not rebuild or resend the assistant conversation-history item array. Its existing-thread path calls thread/resume with threadId only, then turn/start with the current prepared user input and request settings. Prepared input may include application context hints, but this is distinct from serializing assistant/reasoning history.
The resume response's history is not transformed into subsequent turn input. Output-event mapping and text formatting are used for downstream display, not to reserialize assistant history into model requests.
A synthetic test with the transport replaced by an in-memory stub confirmed these outgoing parameter shapes, without any real RPC or model call.
No demonstrated local history-replay defect was found. This code-level audit does not establish the exact historical provider request payload or certify app-server's internal replay behavior.

Evidence limits and expected behavior

Raw provider requests/responses and per-delta evidence are unavailable. We cannot distinguish generation behavior from upstream app-server assembly or labeling. This is not a claim that a reasoning-channel item was routed to the user.
Expected: final user-facing replies should not contain unintended drafting/self-correction fragments.
This is intermittent; there is currently no reliable minimal reproduction. No reproduction has been fabricated.

Privacy

Text-only report. No identifiers, hashes, local paths, conversation transcripts, instructions, credentials, raw logs, screenshots, databases, or attachments are included.

Start with the app-server paths handling thread/resume and turn/start, then trace how assistant output events and history are assembled and labeled. Compare any available provider request/response and per-delta data with persisted message items; done means identifying the source of the draft-like fragments or documenting a reproducible case and the boundary where they enter the final answer.