Critical Error Messages Get Truncated During Output Truncation
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, compilation results, or test execution logs exceed token or byte budgets, the current truncation strategy uses a simple prefix-suffix approach that preserves the beginning and end of content but frequently removes critical error information located in the middle sections. This makes it extremely difficult for users to diagnose compilation failures, test errors, or runtime exceptions because the actual error messages are lost during truncation. The problem is particularly severe when compiling large codebases where error messages appear in the middle or end of lengthy build output, or when running test suites where failure information is embedded within extensive test logs. Users are forced to manually increase token budgets or split operations to see error messages, which is inefficient and frustrating.
What steps can reproduce the bug?
To reproduce this issue, execute a command that generates a large output containing error messages in the middle or end of the output. For example, run a compilation command on a large codebase that produces thousands of lines of build output, with compilation errors appearing after several hundred lines of successful compilation messages. Alternatively, run a test suite that produces extensive logging output before encountering test failures. When the total output exceeds the token or byte budget configured for truncation, observe that the truncation logic preserves the beginning and end of the output but removes the critical error messages that appear in the middle sections. The error information that users need to fix the issues is lost, making debugging impossible without adjusting truncation policies or manually searching through untruncated logs.
What is the expected behavior?
When output contains error patterns such as "error", "failed", "exception", "fatal", "panic", or "abort", the truncation strategy should prioritize preserving these error messages and their surrounding context even when the content exceeds the budget. Error lines should be extracted and preserved along with a few lines of context before and after each error, ensuring that critical diagnostic information remains accessible even in truncated outputs. The system should detect error patterns using case-insensitive matching to handle variations in error message formatting, and should always include error information even if it means truncating more of the non-error content. This would allow users to quickly identify and address failures without needing to adjust truncation policies or manually inspect untruncated output.
Additional information
_No response_
7 Comments
The current behavior is "as designed", so I don't think I'd consider this a bug. While it has some downsides, other solutions have other downsides. Any changes here need to consider tradeoffs. Before you attempt a proposed fix, we should have a discussion.
@etraut-openai ok,thx, please close this bug .
If you have ideas, we can discuss here.
@etraut-openai
Thanks for opening this issue! This is definitely a pain point I've encountered too. Let me share my thoughts on how we could tackle this.
The problem is pretty clear - when you have a big output with errors in the middle, the current truncation just cuts out the middle part, which is exactly where the errors usually are. That's super frustrating when you're trying to debug something.
My approach would be to make the truncation "error-aware" - basically, scan through the output first to find any lines that look like errors (things like "error", "failed", "exception", etc.), and then prioritize keeping those lines even when we need to truncate. I'd use case-insensitive matching so it catches "ERROR", "Error", "error" - whatever format the tool happens to use.
The way I'm thinking about it: first, go through all the lines and mark which ones contain error patterns. Then, for each error line, also mark a few lines before and after it as important (maybe 2 lines of context on each side), because error messages often need that surrounding context to make sense. Then when building the truncated output, always include those important lines first, and only fill in the remaining budget with non-error lines if there's space.
This way, even if the output is huge and we can only keep a small portion, at least the errors and their context will be there. Users can actually see what went wrong without having to mess with truncation settings or dig through untruncated logs.
I also think we should handle multiple errors - if there are several error lines scattered throughout the output, we should try to preserve all of them, not just the first one we find. The algorithm would need to be smart about this, maybe collecting all error line indices first, then expanding each one with context, and finally building the result by prioritizing all those important sections.
The nice thing about this approach is it's backward compatible - if there are no errors, it just falls back to the normal truncation behavior. But when errors are present, they get preserved, which is what users really need.
Pls let me know if you have any comments ,thank you .
@etraut-openai Given your note that this behavior is “as designed” and that changes here are mostly tradeoff-driven, this feels more like an enhancement request than a bug.
Suggestion: consider dropping the
buglabel (or closing as not planned if there isn’t appetite to revisit truncation strategy) and optionally consolidate with #9504 since it’s the same theme (truncation semantics).Is this really not being considered? It's very annoying that Codex sometimes will run a command that outputs, for example, 5000 lines, and only see a small portion of it. And it then has to re-run that command to get the output (if it got lost in the middle) with some redirection/grepping.
IMO Codex should just do the same as its competitors - for commands that output too many lines, just save the output to a temp file and then provide the path to Codex so it can actually read the entirety of it without re-running the command. It's especialy annoying with commands that can take minutes to run.
@etraut-openai Is there any way or plan to support this feature for large tool-call responses without truncation? Maybe make a optional setting somehow to dump raw response?
I am using the Autodesk Revit MCP server to extract data from a 3D model, but I currently have to break requests into batches of five elements to avoid response limits. That makes Codex impractical for this use case.
The workflow I want is simple: pull data from the model, validate it against business rules, and write the results back. VS Code appears to manage this better by dumping large responses to temporary JSON files rather than truncating them in the tool-call output.