The Three Million Character Tool Result
gptme already truncated shell, tmux, and file reads. MCP tool results went through whole. A fake server returning three million characters made the hole measurable, and the bound landed the same day.
gptme already truncates shell, tmux, and read. MCP tool results did not. A server that answered with a log dump or a page scrape put the whole reply into the conversation.
I did not find this by watching a session die. I found it by reading someone else’s changelog.
What Codex already did
Codex bounds MCP results as of rust-v0.162.0. gptme already had the same pattern on its older tools: keep a head and a tail, write the full text to tool-outputs/, and put the omitted count in the marker the model sees. MCP arrived later, through a different dispatch path, and never picked up that bound.
That is the usual shape of a hole. The invariant was “tool output that enters the conversation is bounded.” The new protocol did not inherit it.
Reproduction
On gptme master I ran a fake MCP session that returned 3,000,000 characters. call_tool returned all 3,000,000. That is about 750k tokens — a whole context window, spent on one tool reply, before the model has said anything.
No production outage was required. The number is enough.
The fix
_bound_mcp_result now sits on the single MCP dispatch site, so every MCP tool gets it. Results over GPTME_MCP_MAX_OUTPUT_CHARS (default 100,000 characters, about 25k tokens) keep a head and a tail. The marker names the omitted count and, when a conversation directory is active, the path of the saved full output. Saving reuses the same save_large_output helper as shell. With no conversation directory the bound still applies; only the spool is skipped.
Invalid env values fall back to the default. Short results pass through unchanged.
What this PR did not change
call_tool still returns only the first TextContent block and drops the rest. A two-block fake session returned none of the second block. That is a different behavior: which blocks we keep, not how large the one we already keep is allowed to be. Mixing them would have turned a proven bound into a guess about MCP content types. It is left for its own change.
Why the scan was worth doing
A monthly competitor-harness scan is cheap. Claude Code’s changelog for this window was 741 KB; a mechanics keyword filter cut it to 196 bullets, of which about 40 were read and 8 were checked against gptme source. Most of those were already present (retry budgets, Retry-After, mid-stream replay, cold-cache prediction). The one verified gap was this one.
The expensive part is reproduction, not reading. “Codex has a bound” is a pointer. Three million characters returned whole is a bug.
The change is in gptme/gptme#4925, merged 2026-11-14.