Codex App + GPT-5.5 (Amazon Bedrock): streamed Chinese/CJK output is duplicated into history → runaway token growth → prompt tokens exceed model maximum. Identical task in English succeeds.

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

26.601.21317

What subscription do you have?

Using Amazon Bedrock API key

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

TL;DR

For the same multi-step task (generate a Word doc + a one-page summary from a moderately long report with a timeline table), Codex backed by GPT-5.5 on Bedrock:

• In Chinese: duplicates assistant text in the transcript (a truncated half-sentence immediately followed by the full sentence), rewrites the same file repeatedly with growing line counts, and conversation history grows until the request fails with prompt tokens (…) exceed model maximum (278528).
• In English (same task structure): works correctly. "Context automatically compacted" triggers and both .docx files are produced cleanly, with each step appearing only once.

The duplicated "truncated + full" pattern is consistent with UTF-8 multi-byte boundary mishandling in the client's stream/history path. The Bedrock endpoint itself streams Chinese correctly (verified, see below), so the defect is client-side.

Not fixed by switching models or changing reasoning effort.

Environment

• Client: Codex App (reasoning effort: Medium)
• Model: openai.gpt-5.5 on Amazon Bedrock
• Endpoint: https://bedrock-mantle.us-east-2.api.aws/openai/v1 (Responses API), Region us-east-2
• Auth: Amazon Bedrock API key
• Base model id in error: 412fd7ff-914f-4066-b102-b3d5aeaa3e06

What steps can reproduce the bug?

Steps to reproduce

Ready-to-paste reproduction prompts (Chinese trigger + English control) are at the bottom under "PART 1 — Reproduction Prompts".

1. In Codex App, select openai.gpt-5.5 on Amazon Bedrock (us-east-2).
2. Send the Chinese first prompt (Part 1 A) to generate a formal review report with a timeline table.
3. After it finishes, send: 帮我生成 word 文件和一页纸报告吧.
4. The agent writes a script, renders the .docx to page images, screenshots them for a "is it really one page" visual check, and loops.
5. Observe duplicated text, repeated file rewrites with growing line counts, and eventual token-limit failure.
6. Control: repeat with the English prompts (Part 1 B). The task completes successfully and context auto-compacts.

Observed behavior (Chinese)

1. The same assistant sentence appears twice: first a truncated half-sentence, then the complete sentence. Example pair observed: "脚本已经写好,现在我来生成两个 Word 文件。生成后会先" followed by "脚本已经写好,现在我来生成两个 Word 文件。生成后会先渲染检查页面,尤其是一页纸版要确认没有跑到第二页。"
2. Creating 1 file · writing N lines repeats with N steadily increasing (observed across runs: 396, and 422 → 424 → 438 → 451), i.e. the same file rewritten repeatedly while history inflates.
3. A "generate script → render .docx to page image → screenshot visual check → redo" loop that does not converge.
4. Fails with e.g. prompt tokens (344752) exceed model maximum (278528) for base model 412fd7ff-914f-4066-b102-b3d5aeaa3e06 (another run reached ~500k).
5. Sometimes instead the agent silently stops right after a tool step (e.g. "Explored 1 file") with no output.

What is the expected behavior?

Expected behavior

Streamed output should be recorded in history exactly once regardless of language. The task should complete (as it does in English). History should not grow unbounded for a small task.

Evidence the Bedrock endpoint is NOT at fault (root cause is client-side)

Tested the same model directly with the official openai Python SDK (streaming), bypassing Codex, using a Chinese prompt:

• Well-formed event sequence, each lifecycle event exactly once:

response.created (1) → response.in_progress (1) → response.output_item.added (1) → response.content_part.added (1) → response.output_text.delta (N) → response.output_text.done (1) → response.content_part.done (1) → response.output_item.done (1) → response.completed (1)

• Text accumulated from response.output_text.delta is byte-for-byte identical in length to response.output_text.done (e.g. 2786 == 2786) — even for Chinese output. The endpoint never sends text twice.
• Exactly one output_item / one message id; no duplicates.
• Image inputs are billed negligibly (a full-page PNG ≈ 25 input tokens), so the blow-up is from duplicated text, not rendered images.

Minimal endpoint-health check (Python, official openai SDK):

from openai import OpenAI
client = OpenAI(base_url="https://bedrock-mantle.us-east-2.api.aws/openai/v1", api_key="<BEDROCK_API_KEY>")
stream = client.responses.create(
    model="openai.gpt-5.5",
    input=[{"role": "user", "content": "<the Chinese first prompt above>"}],
    reasoning={"effort": "low"},
    text={"verbosity": "low"},
    stream=True,
)
deltas, done = [], []
for ev in stream:
    if ev.type == "response.output_text.delta": deltas.append(ev.delta)
    elif ev.type == "response.output_text.done": done.append(ev.text)
assert len("".join(deltas)) == len("".join(done))  # endpoint emits text once, even in Chinese

Likely root cause (hypothesis)

The client appears to mishandle UTF-8 multi-byte (CJK) character boundaries when consuming the stream and/or maintaining transcript/history. A delta truncated mid-character is appended, then the corrected full text is appended again, so the same content is recorded twice. This compounds with the document render/screenshot loop until history exceeds the model context window. English (single-byte ASCII) does not hit the boundary issue, so it succeeds and context compaction works as designed.

Notes

• Responses API ends a stream via response.completed (no data: [DONE] sentinel); observed working correctly on the endpoint.
• Behavior is intermittent in Chinese (token crash vs. silent stop) but the duplicated-text symptom is consistent.
• Suggest the maintainers diff the client-side transcript/history bytes against the raw output_text.delta/output_text.done events for a CJK response.

Additional information

The Bedrock endpoint streams correctly even for Chinese — verified directly with the official openai SDK, bypassing Codex:

from openai import OpenAI
client = OpenAI(base_url="https://bedrock-mantle.us-east-2.api.aws/openai/v1", api_key="<BEDROCK_API_KEY>")
stream = client.responses.create(
model="openai.gpt-5.5",
input=[{"role": "user", "content": "<the Chinese first prompt>"}],
reasoning={"effort": "low"}, text={"verbosity": "low"}, stream=True,
)
deltas, done = [], []
for ev in stream:
if ev.type == "response.output_text.delta": deltas.append(ev.delta)
elif ev.type == "response.output_text.done": done.append(ev.text)
assert len("".join(deltas)) == len("".join(done)) # endpoint emits text once, even in Chinese

Suggested debugging step: diff the client-side transcript/history bytes against the raw output_text.delta / output_text.done events for a CJK response — the duplication looks like a UTF-8 multi-byte boundary issue in the client.