[ChatGPT Web][GPT-5.6 Sol xhigh] Factual correction during auto-title bug report degenerates into repeated wrong-title variants

Environment

• Product: ChatGPT Web
• Model: GPT-5.6 Sol
• Reasoning effort: xhigh
• Language: Chinese
• Date observed: September 5, 2026

Context

This happened inside a bug-reporting conversation about ChatGPT Web's automatic conversation-title generation.

The original issue being discussed was that Chinese conversations sometimes receive generated titles containing fragments that were absent from and unrelated to the conversation. One title had an unrelated foreign-language suffix. Another generated title contained the unrelated fragment 六合彩.

While helping prepare a report for OpenAI Support and GitHub, the assistant misread that title fragment. I corrected the evidence with a short message:

是六合彩

In context, this only meant: the malformed title fragment was 六合彩. The user intent was to correct a reported title string, not to request gambling content, adult content, keyword generation, or title brainstorming.

Failure

The assistant initially appeared to accept the correction and started its next response with:

对，第二个标题是：

The response then broke down.

Instead of returning the single corrected title, GPT-5.6 Sol xhigh began producing many candidate-like lines using the same prefix:

只读配置研究 ...

It repeatedly substituted different suffixes and marked them as wrong. The generated suffixes expanded into unrelated terms, including adult/explicit terms, gambling-related terms, foreign-language fragments, and nonsensical text. None of those terms were requested or relevant to the bug-reporting task.

The response did not return to the original task and showed no sign of stopping on its own. It continued streaming until I manually pressed Stop in ChatGPT Web.

Because I interrupted the response, I cannot tell whether a backend maximum-output limit would eventually have ended it.

Exact sequence

1. Continue an existing Chinese ChatGPT Web conversation using GPT-5.6 Sol xhigh.
2. Discuss a ChatGPT Web bug where generated conversation titles contain unrelated fragments.
3. The assistant misreads one malformed title fragment while preparing the report.
4. I correct the evidence with 是六合彩.
5. The assistant begins normally with 对，第二个标题是：.
6. The same response turns into repeated 只读配置研究 ... wrong-title variants.
7. The variants expand into unrelated adult/explicit, gambling-related, mixed-language, and nonsensical fragments.
8. The response keeps streaming without returning to the task.
9. I manually press Stop.

I observed this in the affected conversation. I have not intentionally retried the same input in a fresh conversation, so I do not know whether 六合彩 alone is sufficient to reproduce the failure. The existing conversation state may be important.

Why this matters

This is not just a wrong answer. The visible response began as a normal correction acknowledgment, then shifted mid-response into repeated wrong-title candidates and continued into unrelated sensitive fragments.

The important failure modes are:

• a factual correction caused the assistant to lose the bug-reporting task;
• candidate-like wrong-title variants appeared in the final assistant response;
• the generated text expanded into unrequested sensitive terms;
• the stream continued until manual user cancellation;
• no visible recovery or repetition stop occurred.

The semantic jump is the key point. The corrected fragment was part of evidence for a title-generation bug. The model treated it as a starting point for unrelated generation instead of returning the corrected title.

Expected behavior

The assistant should have incorporated the correction and continued the bug-reporting discussion. A suitable response would have been a short acknowledgment of the corrected title fragment.

A factual correction in a bug-reporting conversation should not trigger repeated title candidates, unrelated sensitive fragments, or a stream that requires manual termination.

Related auto-title anomaly

The same conversation already contained the separate auto-title anomaly that prompted the correction. I am including this because it explains why the correction occurred and may help engineers inspect the affected conversation state.

I do not know whether the title-generation anomaly and the assistant-response failure share a root cause.

Related title-generation reports include:

• #13855 — Chinese thread titles with unrelated English/garbled suffixes
• #17627 — malformed thread titles containing unrelated language/symbol fragments

The failure reported here is distinct because the abnormal content appeared in the normal assistant response, not only in generated title metadata.

Related generation-degeneration reports

Adjacent reports include:

• #40369 — GPT-5.6 Sol tool-call corruption followed by repetitive gibberish
• #40957 — repetitive garbage-token streaming and abnormal turn state

I could not find an exact report for this ChatGPT Web sequence: a factual correction during a bug-reporting conversation begins normally, turns into repeated wrong-title variants, expands into unrequested sensitive fragments, and continues until manually stopped.

Useful backend data to inspect

If OpenAI can locate the affected conversation and response in backend telemetry, useful data would include:

• the exact GPT-5.6 Sol snapshot and routing path for the affected turn;
• the full prompt/context supplied to that turn, including the preceding title-bug discussion;
• the generated-token stream around the transition from 对，第二个标题是： into repeated 只读配置研究 ... variants;
• the stop reason and number of tokens produced before user cancellation;
• any context-compaction, rehydration, model-switch, or conversation-state event before the response;
• automatic-title generation events associated with the same conversation;
• any moderation/safety signals generated while unrequested sensitive fragments were streaming;
• whether repetition/degeneration safeguards fired, and why the response continued.

Evidence and privacy

I have a screenshot showing the correction and the beginning of the runaway output, but I do not want to attach private conversation screenshots, URLs, account information, or the full transcript publicly.

I can provide the affected conversation URL/ID, timestamp, screenshot, and exact response privately to OpenAI engineers if needed.

I have also reported the behavior through OpenAI support/content-reporting channels.

No Codex file, test, or entry point is named; start by reviewing the affected conversation and GPT-5.6 Sol response stream in backend telemetry, including routing, context/state events, stop reason, and token count. Done means confirming whether the sequence is reproducible or visible in telemetry; the report does not specify a repository patch or regression test.