GPT-5.2: hard 10KB tool-output truncation breaks full file reads and MCP results

Resolved 💬 5 comments Opened Dec 12, 2025 by Chriss4123 Closed Dec 13, 2025

💡 Likely answer: A maintainer (Chriss4123, contributor) responded on this thread — see the highlighted reply below.

Issue

The GPT-5.2 harness enforces a fixed bytes truncation policy (TruncationPolicy::Bytes(10_000)). This truncates shell output and MCP responses at ~10KB, which often makes MCP tools get truncated and prevents reading common >10KB files in one call.

Raising the max token limit doesn’t help if the system prompt still tells the agent outputs are capped at 10KB.

What I tested

The system guidance includes a line like “command line output will be truncated after 10KB regardless…”. When I remove that line (leaving the rest of the shell guidance intact), the model does not start spewing huge outputs. It usually keeps reads focused (uses rg, narrow ranges, asks for specific sections) and only requests larger output when needed. Therefore, the model is already fitted well for the Codex agentic workflow where large commands should be truncated by the model, therefore this guidance is largely unnecessary.

Request

Please adjust the truncation policy to tokens so we can use GPT-5.2 to the fullest.

Additional information

_No response_

View original on GitHub ↗

5 Comments

Chriss4123 contributor · 8 months ago

@tibo-openai please take a look at this.

You've literally documented this exact issue publicly, yet we're still facing it with OpenAI's latest frontier model.

We're the ones paying for this product - why does Codex take a sledgehammer approach to truncation that effectively lobotomizes the model?

It makes no sense. The model still caps tool outputs using sed and similar commands EVEN with the truncation policy removed and the system prompt modified. So it's not like removing this cap will cause the model to suddenly fill its context within a dozen tool calls.

GPT-5.2 has clearly undergone SFT with the Codex workflow, just like older models. So why can't we take advantage of the model's intrinsic knowledge of context management? Let it limit tool calls when necessary, but also let it read whole files when necessary.

Nothing is more frustrating than having a 1,500-line API spec and spending two minutes watching the model make 50 tool calls just to read the entire file. Every other popular coding agent allows models to read whole files. Why not Codex?

The new ! command feature doesn't help either: it still truncates. This is even more baffling. If I'm running a command, I want the model to have the full output. Otherwise, why run the whole command instead of selectively extracting what the model needs?

For example, if I run unit tests and ask the model to fix failures, this is useless:

test 1 - passed
test 2 - passed
test 3 - passed
...9853 chars truncated...
test 89 - passed

The ONE thing stopping Codex from going from good to great is precisely this. There's no reason to truncate model outputs with GPT-5.2.

Please fix this.

I already have my own branch with this issue fixed exactly how I described above, and empirical testing via API keys show no degradation or issues (which I documented above too). If I can make a pull request, please let know.

pjongeneel · 8 months ago

etraut-openai contributor · 8 months ago

This will be addressed in the next release.

codengine · 7 months ago

This will be addressed in the next release.

Has this been resolved already? I still see issues with truncated MCP output in 0.79

Dave-London · 5 months ago

This truncation is brutal for MCP tools that return rich data. One approach we've found effective is having MCP servers strip non-actionable fields at the source — Pare does this for common dev tools (git, docker, npm, etc.), returning only the fields an agent would act on via structuredContent. Typical 60-92% reduction means you rarely hit that 10KB wall.