Random Chinese text occasionally appears in scheduled heartbeat messages

Related reproduction on Windows 11 with Codex desktop package 26.715.4045, but outside scheduled automations/heartbeats.

During a normal long-running interactive task that had used subagents and many tool calls, the final assistant response was replaced by a mixed-language fragment plus apparent internal stream/protocol state, including:

... Physics ... connector(connection broke) {"status":"for_sleep", ...}
AGCONNECT(delta) final:
E2 Start attempt failed...

Earlier in the same session, progress messages also intermittently contained unrelated characters or words in otherwise valid Chinese, and failed internal tool-orchestration output was rendered directly in the conversation.

This suggests the affected output-assembly or event-reconstruction path may be shared by heartbeat delivery and ordinary interactive responses, rather than being automation-specific. Expected behavior is that only the intended assistant text is rendered; protocol/event metadata and internal structured fields remain separate.

I also recorded the broader subagent/rendering comparison on #15001. No local paths, credentials, or user project content are included here.

Related reproduction from the Responses API that appears to be the same underlying failure family as this issue and #13867 / #17775.

We are seeing gpt-5.6-terra intermittently corrupt final-answer text at the start of a custom fenced table block whose body is JSON. Instead of beginning the JSON object cleanly, the model emits apparent internal routing/header vocabulary mixed with multilingual glitch tokens. Observed fragments include forms of:

to=functions...
json
assistant
no, final content continue
{Jsii

We have observed three shapes:

1. Recovered: a junk line appears, then valid JSON follows on the next line.
2. Garbled: the junk is fused into the JSON line.
3. Derailed: the response terminates inside the fence, losing the remainder of the answer.

This is present in the raw/persisted assistant message before frontend rendering, so it is not just a Markdown or UI parsing problem.

We built a production-matched replay using the same Responses API adapter, prior conversation history, tool definitions, reasoning effort, and cache settings, with tool execution disabled. On one trigger-prone long history:

• Terra high: 5/11 answers corrupted
• Terra medium: 1/13
• Terra low: 2/6
• Sol low + high: 0/11 answers, across 68 emitted fences
• Luna high: 0/5

The trigger is concentrated in long, many-fence, link-heavy answers. A shorter history remained clean in 12 Terra trials. We also saw two production-shaped occurrences: one recovered and one terminated mid-fence.

This looks closely related to #13867: tool-routing serialization leaking into user-visible output together with under-trained multilingual tokens. The custom JSON fence appears to be a reliable trigger for Terra, while Sol did not reproduce in our current sibling-model controls.

We have implemented defensive scrubbing, tolerant parsing, and retry-on-truncation on our side, but those only mitigate the symptom. I can provide OpenAI privately with the redacted replay corpus, raw Responses API output, request metadata, and reproduction script if useful. Please route this to the model/runtime team as a GPT-5.6 Terra reproduction of the existing tool-serialization leakage class.

Reproduced on macOS with Codex Desktop 26.803.61601 (build 6396).

A recurring heartbeat injected a malformed envelope into the target thread. The saved automation TOML is ASCII-only and has a normal prompt; the corruption was not present in the configured prompt.

Observed received payload fragment:

<heartbeat>
  \u6b73\u5fc3  \u0435\u0442\u0435\u043d\u0442 \u4e45\u4e45\u514d\u8d39\u4e2d\u6587??/ why russian and chinese?

The malformed characters appeared in XML metadata immediately after the opening heartbeat tag, before normal task content. It is therefore not a model answer to the automation prompt and should have been rejected by the scheduler/parser.

Mitigation: paused the affected local automation (gitmama-merge-queue-console) to stop further injections. Expected behavior: heartbeat delivery validates its envelope as UTF-8/XML (or rejects it) and never renders corrupted metadata as conversation content.