[amazon-bedrock] Streaming emits cumulative snapshots as duplicate agent_message items (Mantle/Responses)

Open 💬 2 comments Opened Jun 24, 2026 by yjiseok

Summary

With the built-in amazon-bedrock provider (Mantle Responses API), a single assistant turn emits many agent_message item.completed events whose text is the monotonically-growing cumulative snapshot of the same final message. The client persists each streaming snapshot as a separate completed message item instead of coalescing deltas.

Environment

  • codex-cli 0.142.0 (latest stable) AND 0.143.0-alpha.9 — both affected
  • Provider: amazon-bedrock (built-in, Mantle Responses path)
  • Region: us-east-2, model openai.gpt-5.5
  • macOS (Apple Silicon)

Repro

codex exec --json --skip-git-repo-check "<long prompt yielding a multi-chunk response>"

Observed

A single turn emits N agent_message item.completed events; text length grows monotonically (same final message repeated as ever-longer prefixes):

  • 0.142.0: 31 items, text length 189 -> 4049
  • 0.143.0-alpha.9: 16 items, text length 295 -> 3386 (same pathological pattern)

Short single-chunk responses emit only 1 item, which masks the bug (a one-line "OK_ONCE" test looks fine).

In the TUI this renders the answer repeatedly/growing; the rollout jsonl also stores the duplicate message items (distinct ids) for one turn.

Expected

One agent_message item per assistant turn (output_text deltas/snapshots coalesced), as on the OpenAI-hosted Responses path.

Notes

  • Not reproduced on the OpenAI-hosted Responses path; appears specific to the Bedrock Mantle streaming adapter.
  • model_reasoning_effort (xhigh/high/medium) has no effect — duplicate count tracks response length, not effort.
  • The built-in amazon-bedrock provider ignores stream tuning knobs (stream_idle_timeout_ms, stream_max_retries, wire_api), so there is no user-side config workaround.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗