· via dev.to (home feed)
Silent 10,000-token truncation left Codex CLI agents judging files they never fully read
A dev.to write-up documents Codex CLI silently cutting tool output at 10,000 tokens, so agents judged half-read files; prescribing exact call headers solved what explanations could not.

A developer running a coordinated team of LLM agents has documented a reliability failure in Codex CLI: tool outputs were being silently truncated, and the agents went on making decisions from files they had never finished reading. According to a post on dev.to, the setup uses several agent roles that coordinate through markdown files, with some running on Codex CLI 0.165.0, which executes tool calls in code mode.
On October 24 the author audited the sessions and found that, of 33 Codex sessions working toward a single goal that day, 31 contained at least one truncated tool output — 129 cuts in total. Among the lost material were a reviewer's findings and the very work plan an agent was executing. The agents then proceeded on what remained.
How the truncation hides itself
An oversized output does not fail the call. As described on dev.to, it begins with a warning line stating the original token count, retains the opening and closing sections of the text, and silently drops the middle, marking the gap with an ellipsis such as …4107 tokens truncated…. Because the model still receives the start and the end, a file can look complete at a glance — minus the middle, which is typically where the substantive detail sits.
A first fix that didn't hold
Codex exposes a config value, tool_output_token_limit, that caps tool output. It sat at its default of 10,000 tokens while the author's largest document ran to roughly 39,000. Raising it to 40,000 cleared most cuts, leaving only process dumps and test JSON truncated.
A second, per-call budget, max_output_tokens, is set by the model itself. Rather than measuring every file before reading it, the author explained both budgets in the agent's instructions and left the values to the model's judgment.
Six days later, outputs were still being cut — 11 percent of them, down only slightly from 13 percent the week before. Replaying one session showed every cut stopping at about 10,000 tokens, even when the model had requested 18,000 or 26,000.
A third, hidden limit
The cause was a third ceiling. In code mode, the model's commands run inside a JavaScript exec cell that carries its own output budget, set by a first line reading // @exec: {"max_output_tokens": 40000}. Without that pragma, the budget defaults to 10,000 no matter what the commands inside the cell asked for. Across 9,538 calls from five days of logs, the model wrote the pragma 137 times. The dev.to post notes this is a known issue, openai/codex#33402, open since July.
Rewriting the instructions did not help. The author revised the guidance twice, the second time stating outright that the smaller of the two budgets is the binding one. Across four replays, 19 of 24 calls were cut and the model wrote the pragma zero times.
Prescribing instead of explaining
What worked was removing the choice. The instruction now mandates one fixed value: every exec call begins with the pragma line set to 40,000, and every exec_command carries max_output_tokens: 40000. It also directs the agent to judge only from text actually received and to re-read any truncated section a decision depends on.
In three replays, all 16 calls carried both budgets. Three were still truncated — each a batch of eight or more files that together exceeded 40,000 tokens — and in each case the model went back and read the missing portion in ranges.
The post closes with an audit method: session logs live under ~/.codex/sessions/, with older ones compressed as .jsonl.zst, and searching them for the truncation marker counts how often reads were cut short.
Why it matters
Agent workflows rest on the assumption that a tool result reflects what the tool actually returned. Here the failure was silent, frequent and structural: truncation preserved the beginning and end of each file, making incompleteness easy to miss, and the limit that actually bound output was one the main configuration did not control. The post also carries a broader lesson for anyone directing agents — explaining a constraint in prose was consistently less effective than removing the decision and dictating the exact call format. Teams running Codex CLI in loops can gauge their own exposure in minutes by counting truncation markers in their session logs.
- #codex-cli
- #openai
- #ai-agents
- #truncation
- #reliability