JSON and XML Structured Data Gets Truncated in Ways That Break Parseability
What version of Codex is running?
v 0.87.0
What subscription do you have?
None
Which model were you using?
gpt-5-codex
What platform is your computer?
Microsoft Windows NT 10.0.26100.0 x64
What terminal emulator and version are you using (if applicable)?
Powershell
What issue are you seeing?
When tool outputs return large JSON responses from APIs, configuration files in JSON format, or XML documents that exceed token budgets, the current truncation approach treats structured data as plain text. This results in malformed JSON or XML that cannot be parsed, such as truncating in the middle of a string value, breaking object or array structures, or leaving unclosed tags. The truncated data becomes useless for downstream processing or analysis because it cannot be parsed by standard JSON or XML parsers. This issue commonly occurs when working with API responses, configuration files, or data exchange formats where the structure and parseability of the data is critical for further processing.
What steps can reproduce the bug?
To reproduce this issue, execute a tool call that returns a large JSON or XML response, such as calling an API that returns a JSON object with many nested properties, or reading a configuration file in JSON format that exceeds the token budget. When the truncation logic is applied, observe that the JSON or XML structure is broken - for example, a JSON object might be truncated in the middle of a string value, leaving an unclosed quote, or an array might be cut off without a closing bracket. Attempt to parse the truncated output using a standard JSON or XML parser, and observe that parsing fails with syntax errors because the structure is no longer valid. The data becomes completely unusable even though portions of it might have been preserved.
What is the expected behavior?
When truncating JSON or XML content, the system should detect the data format and apply structure-preserving truncation strategies. For JSON content, the system should attempt to parse the JSON first, and if parsing succeeds, preserve the top-level structure by keeping all object keys or array elements but may truncate nested values or mark them as "[truncated]" when budget is exhausted, ensuring the result remains valid JSON that can still be parsed. For XML content, the system should preserve the XML structure by keeping opening and closing tags balanced and truncating content within tags rather than breaking the tag structure. The truncated output should always remain parseable by standard parsers, allowing downstream systems to process the data even if some content has been removed. Format detection should use simple but effective heuristics such as checking if content starts with '{' or '[' for JSON, or '<' for XML.
Additional information
_No response_
6 Comments
The current behavior is "as designed", so I don't think we'd consider this a bug. While the current behavior has some downsides, other solutions have other downsides. Any changes here needs to consider tradeoffs. If you have ideas, let's discuss.
@etraut-openai
Thanks so much for opening this issue! This is a really important problem that affects usability, and I'm glad you brought it up. I've definitely run into this myself - it's super frustrating when you get a JSON or XML response and it becomes completely unparseable after truncation.
I'd love to share some thoughts on how we could approach this. The core idea would be to detect when we're dealing with structured data and handle it more intelligently. For JSON, we could check if the content starts with '{' or '[' and try parsing it first. If it's valid JSON, we can preserve the structure while truncating content - maybe keep all the top-level keys but mark nested values as "[truncated]" when we run out of budget. That way, the output stays valid and parseable even if some data is removed.
For XML, we'd follow a similar approach - keep the tag structure balanced and truncate content within tags rather than breaking the tags themselves. The key is making sure whatever comes out can still be parsed by standard parsers.
I think the detection could be pretty straightforward - just look at the first few characters to guess the format, then try parsing to confirm. If we can't detect it or parsing fails, we'd fall back to the normal truncation behavior, so it's backward compatible.
This should make a big difference for anyone working with API responses or config files. What do you think? I'd be happy to help implement this if it sounds good!
Our truncation limits are quite large — significantly larger than a typical JSON or XML response. Do you have real-world examples of where truncation has been a problem? If so, it would be instructive for us to see an example. If you have such a session, please use the
/feedbackslash command to upload the session details and post the thread ID here.We are working on some alternative mitigations for large tool output. These techniques don't rely on heuristics like those that you're describing in your proposed solution. We prefer to avoid heuristics. They tend to work well for common patterns but fail in ways that are unexpected and difficult to debug.
@etraut-openai
actually it works well in claude code (we can't reproduce), but it exists when we use codex. The data is confidential ,so i can't upload it here ,but just the same as what i mentioned here. During some reason ,we need to use open-sourced solution in our environment,that's why we adopt this excellent framework-codex ,but it indeed occurs this issue. If not fix ,we need to consider other solution .
That's the background .thanks ~
OK, understood.
As I mentioned, we're experimenting with ways to mitigate the tool truncation issues. These techniques use local (temporary) files.
In the meantime, you can specify a larger
tool_output_token_limitin yourconfig.tomlfile. The default is 10,000 bytes. If you are using tools that produce JSON or XML output larger than this, you can adjust as necessary.@etraut-openai Similar to #9502, this seems more like an enhancement request than a bug (truncation strategy vs parseability tradeoffs), especially given the existing workaround guidance (
tool_output_token_limit).Suggestion: consider dropping the
buglabel (or marking as not planned) and consolidating discussion with #9502 so truncation-related proposals stay in one thread.