I run a small team of LLM agents that coordinate through markdown files. Several roles run on Codex CLI 0.165.0, which runs their tool calls in cod...
For further actions, you may consider blocking this person and/or reporting abuse
The "31 of 33 sessions had a truncated read and the agents decided anyway" number is the scary part — not that truncation happens, but that it's silent and the model treats the start+end of a file as the whole thing. We hit the same class of bug with agents coordinating through markdown and landed on a slightly different mitigation: instead of tuning the three budgets to fit the biggest document, we made the read tool fail loudly when it truncates, returning an error the agent has to handle (re-read in ranges) rather than a warning it can read past. Truncation-as-error beat truncation-as-warning for us because models reliably ignore the warning line once there's a plausible-looking body after it. The
wc -cbefore read is the right instinct too; we front-loaded it into the tool itself so the model can't skip it. One question — did you ever see an agent notice the…N tokens truncated…marker and self-correct without you prompting it? In our logs that basically never happened, which is what convinced me warnings aren't enough.Never on its own. That's why it went unnoticed for so long the first time. That was in another project, a classification system where an agent read a lot of material and sorted it by a set of rules. The results followed the rules less closely than they should have, and I kept digging until I found the cut reads.
I didn't make truncation an error because these agents don't do one fixed job, and I don't have enough cases yet to know what an agent should do after each kind of error. The team works this way in general: start nondeterministic, then move whatever settles into deterministic code. So it's useful to hear that the error approach holds up in practice for you.
This is exactly the kind of failure a completion signal must make explicit. Before an agent judges a repository-wide property, the workflow should expose coverage: files discovered, files read, skipped paths, truncation events, and the confidence permitted by that evidence. Otherwise fluent output launders partial observation into certainty.
Fluent output is what kept this hidden. The verdicts gave no sign that part of a file was missing. Of the things on your list, truncation events are the one Codex already leaves behind: the marker stays in the session log, and the grep at the end of the post counts them.
Prompting the model to pass
// @exec: {"max_output_tokens": 40000}breaks down because token budgets belong at the harness boundary. When the context window fills up or multi-step tool loops chain together, prompt instructions get dropped. Even with the 40k pragma hardcoded, middle-truncation with exit code 0 remains dangerous because the model receives valid text with an inline marker and continues as if the document were whole. Moving the contract into the tool wrapper by throwing an immediate exit code or returning byte ranges likeread_file(path, offset, limit)prevents the agent from running on half a plan. Raising the buffer to 40k buys temporary space, but any 60k test log or schema dump will trigger the exact same silent truncation.Agreed that this belongs in the harness. The 10,000-token default on the outer exec cell is what openai/codex#33402 is about, and I'd rather see it fixed in Codex than have every prompt carry a pragma.
For now, only tool_output_token_limit can be set from outside, in config.toml or with -c on codex exec. The other two budgets are set per call by the model, and the smallest of the three wins, which is why raising the ceiling alone didn't help.
On this team the work is routine enough that 40k covers most reads, and when a batched read goes past it, the agent rereads the cut part in ranges.
A verdict on a file that was only half read is a verdict on the half that was read. Make the judge log the last line it reached before it decides, and refuse a verdict whose range doesn't cover the file. One number per file turns a silent gap into a visible one.
Right, a verdict only covers what was read. Logging the last line would catch a cut that drops the end of a file. Codex drops the middle instead, so the agent still reaches the last line and the read looks complete.
What I've settled on for now is making the cut rarer and cheap to repair: the same 40,000-token budget on every call, and when a read still gets cut, the agent rereads only the missing range.
Judging a file it never finished reading is a fun way to get confident wrong reviews.
Very fun. 129 times in one day.
129 times in one day makes the confident part hard to argue with.
the cut-off middle is usually where the details lived
Yes, and the start and the end are still there. That's enough for the agent to carry on as if it had read the whole file.