MCP tool results show "...N tokens truncated..." in Codex even when the upstream MCP server returned the full payload

Open 💬 1 comment Opened Mar 12, 2026 by reoLantern

What version of the Codex App are you using (From “About Codex” dialog)?

26.309.31024 (962)

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Summary

When an MCP tool returns a large text payload, Codex shows ...N tokens truncated... inside the tool result in the conversation.

However, in my testing, the upstream MCP server did return the full payload over HTTP. The truncation appears to happen in Codex's tool-result display / result-carrying pipeline, not in the MCP server itself.

This is misleading for both users and agents, because it makes it look like the MCP server truncated the result.

Why this matters

This breaks workflows that depend on complete long-form MCP outputs, such as:

  • full-paper translation
  • long document review
  • log analysis
  • large JSON/text inspection

The agent cannot reliably tell whether:

  1. the upstream tool/server truncated the content, or
  2. Codex only truncated the displayed/accessible result locally

Notes

I do not believe this is a bug in the MCP server I tested against.

I inspected the upstream server behavior and verified that the raw HTTP response was complete. The truncation appears to be introduced after that, inside Codex.

What steps can reproduce the bug?

Reproduction

I reproduced this with a local Zotero MCP server (zotero-mcp plugin from here) on March 12, 2026.

  1. Start a local MCP server that can return a very large text payload.
  2. In Codex app, call an MCP tool that returns full document text.
  3. Observe that the tool result in the conversation contains text like:
...20330 tokens truncated...
  1. Make the exact same MCP request directly against the local HTTP endpoint with curl.
  2. Save the raw HTTP response to a file.
  3. Inspect the saved file: the raw response is complete and does not contain the ...N tokens truncated... marker.

Concrete example

I tested with Zotero MCP get_content(..., mode="complete", format="text").

Inside Codex, the tool result showed truncation markers such as:

...20330 tokens truncated...

But direct HTTP requests to the same local MCP endpoint returned full JSON payloads:

  • raw response file size for one paper: ~129 KB
  • raw response file size for another paper: ~63 KB

I also searched the saved raw JSON responses for:

  • tokens truncated
  • truncated

and found no such marker in the upstream response.

What is the expected behavior?

Expected behavior

One of the following should happen:

  • Codex should preserve the full MCP result for agent access, even if the UI only shows a preview
  • or Codex should explicitly label this as display truncation only, not upstream tool truncation
  • or Codex should provide a way to fetch / inspect the full raw tool payload
  • or Codex should support paging / file-backed handling for large MCP results

Actual behavior

Codex inserts a truncation marker into the visible tool result, making it indistinguishable from real upstream truncation.

Environment

  • Codex app
  • local MCP server over HTTP
  • reproduced with Zotero MCP
  • observed on macOS

Additional information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗