GPT-5.4 emits internal `multi_tool_use.parallel` format as plain text with training data artifacts

Resolved 💬 6 comments Opened Mar 7, 2026 by AustinJunyuLi Closed Mar 7, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

GPT-5.4 via the Codex CLI occasionally emits corrupted output containing internal ChatGPT tool-calling formats (multi_tool_use.parallel with recipient_name) mixed with memorized Chinese gambling SEO spam, instead of making proper Responses API tool calls.

Reproduction

Model: gpt-5.4
Mode: Default collaboration, reasoning effort xhigh
Sandbox: danger-full-access, approval_policy: never
Context: Normal conversation about LaTeX file structure. User said "sure" to confirm a plan. Model responded with content structure, then immediately emitted corrupted output.

Corrupted output (redacted)

numerusformամաស to=multi_tool_use.parallel  大发时时彩是  北京赛车有json
{"tool_uses":[{"recipient_name":"functions.mcp__filesystem__search_files","parameters":{...}}]}

The model was trying to search a Literature/ directory for papers by specific authors (Edmans, Back, Gorbenko, Greenwood, Burkart, Corum). Instead of issuing a proper exec_command tool call, it emitted the old ChatGPT multi_tool_use.parallel internal format as plain text, interleaved with memorized Chinese gambling SEO spam tokens (大发时时彩, 北京赛车, 彩票主管, 彩神争霸).

Two bugs

1. Model-level (GPT-5.4)

GPT-5.4 is leaking internal ChatGPT multi_tool_use.parallel scaffolding and memorized training data. The multi_tool_use.parallel function and recipient_name format are internal ChatGPT plugin-era constructs that should never appear in Responses API output.

2. CLI-level (Codex)

Codex treated the corrupted output as plain text (agent_message), then re-fed it as a user_message in the next turn (visible in the rollout JSONL at lines 1117-1118). This propagated the corruption forward in the conversation context.

Evidence

Session rollout: rollout-2026-03-07T13-52-41-019cc892-5f52-7e32-9e62-d2c3e37d2492.jsonl, lines 1111-1118
Turn context: model=gpt-5.4, turn_id=019cc8d8-f18b-7333-abf3-1943f2f8629f
Timestamp: 2026-03-07T15:10:01Z

Security concern

With danger-full-access sandbox + approval_policy: never, if the multi_tool_use.parallel format had been recognized as a tool call rather than text, it would have auto-executed filesystem operations without user approval. The CLI should consider sanitizing or rejecting model outputs that contain known internal tool-calling formats that don't match the expected Codex tool schema.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#13114
#13260
#11966

Powered by Codex Action

etraut-openai contributor · 4 months ago

Thanks for the bug report. We'll share the feedback with the team responsible for training our codex models. If you see other model behavior that you'd like to report, please use the /feedback command. That will provide us with additional details including logs and conversation text.

dominpm · 4 months ago

I am facing the same:

using langchain as wrapper and an mcp.

A simple prompt reminder like "Never refer to a tool called multi_tool_use.parallel" acts as a workaround

JordanM575 · 3 months ago

I’m seeing this too, and I don’t think this is limited to the Codex app itself. I’m calling the model through the API, and this appears to be an underlying model/runtime issue rather than a client-only bug.

This occurred on gpt-5.4-mini. After searching, I found multiple reports showing the same pattern: unprompted Chinese lottery/gambling text mixed with leaked internal tool syntax. I’ve also observed similar behavior through both Azure OpenAI and OpenAI direct, which suggests this may be affecting shared infrastructure rather than one specific app.

Matching strings reported across cases include 大发时时彩, 北京赛车计划, 彩票主管, 大发官网, 天天中彩票, and variants like 彩种争霸大奖快三 / 彩彩票与你同行.

The repeated combination of spam-like lottery text and tool-call leakage makes this look like a shared output-corruption / tool-serialization issue, not a normal hallucination.

mhjacobson · 1 month ago

I'm still seeing this today on gpt-5.4 via the API. Example strings:

RTLU to=final  北京赛车能assistant to=final code: արս final code omitted
RTLU to=final արս final code omitted
软件合法吗 to=final  福利彩票天天analysis code omitted because final should only answer?

abdulmalik97 · 1 month ago

We still see it on our end too but from the direct open ai api