Configurable tool output truncation limits via config.toml

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #4550
• #5163
• #5095
• #4398

Powered by Codex Action

Thanks for the feature request.

One of the challenges with what you're proposing is that the gpt5-codex model is trained with the 256-line limit in place. It learns during its training that it should not exceed this limit. You'll see, for example, that it reads files in 256-line chunks. Changing this behavior would require more than a configuration option. It would require retraining the model so it understands and honors the configured limits for each tool.

@etraut-openai Thank you for the response and for your work on Codex CLI.

I believe there may be a misunderstanding about the scope of the feature. The feature doesn't change how the model requests data (it would still request 256-line chunks as trained). Instead, it addresses what happens AFTER the tool executes.

For example:

• Model requests: sed -n '1,256p' file.rs
• Tool returns 256 lines as requested
• Those 256 lines might be ~15-20 KiB of Rust code (they often are I think)
• Currently: Output is truncated to 10 KiB before sending to model
• With this feature: User could configure that 10 KiB limit

Indeed, the logs show that gpt5-codex consistently reads files using something like sed -n '1,240p' file.rs. The model's trained behavior would remain unchanged. We're only making the post-execution truncation configurable.

Please let me know if this clarifies your concerns.

Thanks for the clarification.

I started using Codex for the first time last week, and set up the Chrome and Atlassian MCPs. I set Codex to work on a complex task and had it create a number of Confluence pages to plan and track its progress, which was all initially working fine.

However at a certain point Codex got stuck, and was only able to read the first 10,240 characters of a Confluence page it had just created. I couldn't find any workaround for or even explanation of this limit. Ultimately this meant that my approach to the task was no longer viable, which was disappointing to discover after I'd invested quite a bit of time and effort in the setup.

(I'm still not 100% clear on whether MCPs are subject to the same limit as tool calls, but this seems the most likely explanation. Please point me to a different issue if not.)

I started using Codex for the first time last week, and set up the Chrome and Atlassian MCPs. I set Codex to work on a complex task and had it create a number of Confluence pages to plan and track its progress, which was all initially working fine. However at a certain point Codex got stuck, and was only able to read the first 10,240 characters of a Confluence page it had just created. I couldn't find any workaround for or even explanation of this limit. Ultimately this meant that my approach to the task was no longer viable, which was disappointing to discover after I'd invested quite a bit of time and effort in the setup. (I'm still not 100% clear on whether MCPs are subject to the same limit as tool calls, but this seems the most likely explanation. Please point me to a different issue if not.)

@lachlancooper Since it could only read the first 10,240 characters of the page, it's likely that Codex hit the hardcoded limits (10 KiB or 256 lines). According to Codex's MCP internals, MCP requests are considered a type of tool call and are therefore subject to the same hardcoded tool output truncation limits that I discussed here.

To confirm this, go to the .codex/ folder where your config.toml is located. Inside the folder, open the session rollout log in the .codex/sessions folder. The log ends with the session ID that Codex provides to you if you want to resume the conversation (e.g., .codex/sessions/2025/11/02/rollout-{date}-019a52f9-ec3b-7050-8f8f-a4965529e279.jsonl). Search inside it for a substring like: [... output truncated to fit 10240 bytes ...] or [... omitted 34 of 324 lines ...]. Check to see if this substring appears in the middle of the Confluence page that you expected Codex to read. If so, then you have reached the hardcoded tool output truncation limits.

My feature suggestion would allow you to configure these limits at your discretion via the config.toml file or temporarily with a command. As I mentioned in my suggestion, when truncation occurs, Codex indicates where the removed content was before sending it to the model. These markers ensure the model knows the content was omitted and how. We expect the model to recognize this and request the missing content using another tool or MCP call. Is the Confluence page content gathered by a tool call in Chrome MCP or in the Atlassian MCP? Check if the tool call contains a field that allows the model to customize the portion of the page it wants to read, such as the number of bytes or the starting and ending lines, or if it allows some kind of pagination mechanism to read it. The model should know that from the MCP tool call spec/description. My feature request would be helpful in cases where the model's performance is overwhelmed and it forgets to request missing content, or when the tool always tries to send all the content at once.

You can try prompting the model specifically in the request. Tell it to pay strict and careful attention to any omitted or truncated content, and instruct it to gather the missing content.

Thank you for the very detailed explanation. According to Codex, the definition of the getConfluencePage resource it was using is:

type mcp__atlassian__getConfluencePage = (_: {
  cloudId: string,   // Unique identifier for an Atlassian Cloud instance (UUID or site URL)
  pageId: string,    // Numeric Confluence page ID
}) => any;

So I suppose this is also an Atlassian MCP limitation. There's no way to select a particular portion of a page, so Codex can only ever see the first 10,240 characters.

It seems that the getConfluencePage resource always returns the full content. There are no fields for pagination or for returning a specific portion of the content. Codex will truncate the full content at the hardcoded limit of 10 KiB (~10,240 characters) before sending it to the model. The truncation preserves the beginning and end of the content, marking where the middle was removed. Even if the model acknowledges the marker and realizes that truncation occurred, there is no way for it to request the missing portion because the getConfluencePage resource always returns the full content.

My PR for adding configurable tool output truncation limits would solve this issue (cc @etraut-openai). It would also establish groundwork for more sophisticated truncation strategies.

I need this... bad. 10kiB is an absurd limit. I get that tool outputs should be shorter than that, but several of my MCP tools break this. My linear one just returns the contents of the issue, which can get long, but importantly, my agent NEEDS all that context. The worst part, is it never acknowledges it, it just keeps on going with incomplete data. Doesn't care that it got cut off, just wants to keep going.

Please please please... we need a way to adjust this limit. even up to like 20kb. But ideally we just can configure it to be higher, like @insilications has done.

My MCP's work fine in cursor. I don't see how this helps us codex users. It can still absolutely be set at 10kiB default. Most users won't have to touch it. But us power users can set a config value to bump it up.

this is a bit misleading.. the model says "Read" but in reality he just chunk a piece of it .. u cant tell he read the file entirely or not, but we all know that if he read the top only --> he will inventing the rest.
its also not clear the limits of mcp tools tokens/size outputs, neither shell commands. wether a cat of a 1000 LOC file will go thru or not.
it would be ideal that:
1) these constants / values of tool call are published, ideally a config value
2) known when there is overflow so we are aware that the model hasn't accomplished readings
3) Read vs PartialRead would be ideal to known as a different event/task/tool whatever
4) if you can force the model to read full files and behave on offset/sliding required, will be also great.

I wrote up my own issue today which was just linked there, not knowing this one existed.
A config would be a fantastic option to start, and I think model training should not matter if users want to diverge from the defaults.

That said I think arbitrary 256 line limits are extremely limiting, and going for token based limits make a lot more sense.
The crazy thing is that this did not start impacting MCP tools until the 0.56 release, and I've personally noticed a massive quality degradation as a result. There are more than just file read tools - search tools for instance, the model doesn't know what the response will look like, and cutting off responses in the middle is a poor experience, especially if the tool plans around Claude's 25k token limit instead.

That said I think arbitrary 256 line limits are extremely limiting, and going for token based limits make a lot more sense.

Well said. I can incorporate token-based limits into my draft PR. All I need is the Codex team's approval to open it.

> That said I think arbitrary 256 line limits are extremely limiting, and going for token based limits make a lot more sense. Well said. I can incorporate token-based limits into my draft PR. All I need is the Codex team's approval to open it.

Unfortunately they no longer accept any external contributions. Just have to wait for them to address this.

Thanks for the implementation @etraut-openai

Don't see this implemented anywhere, but I've posted an update on #4550 with a link to a patch and walkthrough on how to force this through while waiting for the penny to drop that truncating lines is a critical securiity/UX issue.