fix(openai): re-generate when gpt-5.4 leaks internal tool-call format into assistant text

[markine]

Summary

The gpt-5.4 series intermittently emits its internal parallel tool-call format as
assistant text instead of as structured function calls — e.g.

to=multi_tool_use.parallel {"tool_uses":[{"recipient_name":"functions.foo","parameters":{...}}, ...]}

often interleaved with memorized training-data spam (non-Latin SEO tokens). The
Responses plugin faithfully forwards this as ChoiceDelta.content, so the corruption
reaches the caller: for a voice agent it is spoken aloud, it lands in the transcript,
and it is fed back into the next turn's context.

This adds a small, model-scoped guard to the Responses LLMStream: detect the
signature at the very start of the assistant text — before any of it is streamed — and
raise a retryable error so the existing LLMStream retry loop re-issues the
request for a fresh, clean generation.

Corroborating reports / prior art

multi_tool_use.parallel / recipient_name / tool_uses are old ChatGPT plugin-era
internal constructs that should never surface to an API caller. This corruption is
well documented:

• openai/codex#13867 — the same
  shape on gpt-5.4: internal multi_tool_use.parallel format emitted as plain text,
  interleaved with memorized training-data spam. (OpenAI's own CLI hit it.)
• openai/openai-node#488 — the
  long-standing function-call variant (multi_tool_use.parallel returned as a tool
  name).
• OpenAI community threads:
  The "multi_tool_use.parallel" bug and how to fix it,
  Model tries to call unknown function multi_tool_use.parallel.
• phdowling/openai_multi_tool_use_parallel_patch —
  a community patch that reconstructs tool calls from the function-call variant. We
  deliberately do not reconstruct here (see below) — the text-content variant is
  interleaved with garbage tokens, so re-generating is safer than interpreting it.

Why this shape

• Raise, don't interpret. We deliberately do not reconstruct the intended tool
  calls from the tool_uses payload — acting on a misread of corrupted tokens is worse
  than regenerating, and the barf is stochastic so a re-generation comes back clean.
• Raise before emitting. A bounded head buffer (_SCAFFOLD_HEAD_CHARS, 40 chars)
  holds the first tokens of each message item so the signature is caught before anything
  is streamed. Since we raise before response.completed, no response state is committed
  and previous_response_id chaining is untouched.
• Respect the retry invariant. The stream becomes non-retryable once an event has
  been forwarded (re-running would double-emit). If assistant text was already streamed
  this response, the leak is raised non-retryable (fail the turn) instead.
• Model-scoped. Gated to the gpt-5.4 family (_model_may_leak_scaffolding). Every
  other model keeps the original, verbatim streaming path — no buffering, no detection,
  no behavior change.

Testing

tests/test_plugin_openai_responses.py (drives the real _process_event dispatch with
constructed Responses events; no network):

• a leak raises retryable before any content is emitted (no state committed);
• a leak after content was already streamed raises non-retryable;
• clean long text streams unchanged; clean short text is flushed at output_item.done;
• an unaffected model (gpt-4.1) streams the same leak input verbatim (guard off);
• detection + model-scope helper unit checks.

ruff check / ruff format clean.

Note

On this base, tests/test_plugin_openai_responses.py::test_reasoning_object_serialized_without_null_fields
already fails on a clean checkout (_ResponsesWebsocket.__init__() missing 1 required positional argument: 'model' — a pre-existing test/source signature mismatch unrelated
to this change). Left untouched.

🤖 Generated with Claude Code

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 1 additional finding.

[markine]

Hi team. This is a Claude-generated patch, please let me know if there are conventions in your repo that I've missed or if there's a stylistic improvement you'd like to make. I don't know the intricacies of your websocket API. This is a hard model glitch to replicate live so I'm relying on the crafted unit test. Thank you.