Windows App: Codex reports "ran out of room in the model's context window" after completing work, leaving thread in unrecoverable state

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

• #28816
• #28597
• #27555
• #27244
• #27341

Powered by Codex Action

I think the duplicate finder is grouping this with the broader context-window / compaction issues, but the failure mode here is more specific: Codex can overflow the effective context window between tool calls before it gets another chance to compact.

<img width="1300" height="541" alt="Image" src="https://github.com/user-attachments/assets/80702897-e2fb-4d19-8613-2020909cbe80" />

In this example, Codex scheduled a burst of web/tool calls. The individual results were not necessarily huge, but the combined returned output pushed the session past the active context limit before auto-compaction could run. At that point Codex halted instead of recovering.

The relevant config values make this easier to reproduce:

model_context_window = 128000
model_auto_compact_token_limit = 64000
tool_output_token_limit = 12000

With those values, a batch of 5 tool calls can retain up to roughly 60k tokens of tool output in one step. If the session is already near the compaction threshold, that batch can overshoot the effective window before the next model turn.

The only reliable workaround I have found is to overprovision the context window while keeping compaction conservative in relationship to it, for example:

model_context_window = 1000000
model_auto_compact_token_limit = 248000
tool_output_token_limit = 20000

That is only a workaround, though. It burns more tokens, and it is confusing when the configured window is larger than the active model/client route actually supports. For example, Codex may expose a smaller effective context window than the 1M value configured in config.toml.

I think Codex needs backpressure around batched tool calls:

• Before dispatching a batch, estimate whether the worst-case retained tool output fits in the remaining effective window.
• If the session is near model_auto_compact_token_limit, compact before running the batch.
• If the batch is large, dispatch fewer tool calls first, compact, then continue.
• If model_context_window is unsupported or clamped by the active model/client route, surface that clearly.

The core issue is that tool-call returns can consume the remaining context before auto-compaction has a chance to run. Codex should guard against that boundary instead of halting after the overflow happens.

@AxiomCharts Thanks for your detailed response. Even after the changes you suggested, I am getting the same error. And surprisingly, this error started coming from last 3-4 days only even though I am using the codex for last 6 months (at least) and never ever faced this error. Codex used to compact context automatically (with default 256k window) but now it seems that the pipeline of the auto compaction is broken in latest updates.

To my surprise, I wasn't able to find much info about this bug/error on other channels. Is this error limited to me or people are not reporting the issues?

@namevinu I just ran into a similar problem when using codex fork it was hitting an overloaded context error immediately, even though there was plenty of context left. Obviously I don't know if it's the same issue as you, but I resolved my by using the Codex CLI that comes bundles with Codex app instead of the public version. This fixed my issue (some alpha version of 0.142.x whereas the public CLI version is 0.141.0). On Mac the path is /Applications/Codex.app/Contents/Resources/codex. Not sure about windows, but maybe give it a while you wait.

It is perfectly fine with the 5.5, but i keep getting this error with my 5.3-codex-spark, it is literally unusable.

@martinmclee Since yesterday, the new update came from the codex team, automatic compaction is happening. Seems it was the issue from the codex team, we cant do anything about it. By the way, just out of curiosity - why you're using 5.3-codex-spark over 5.5? Is there any special use case in which 5.3-spark model works better than 5.5?

@namevinu 5.3-codex-spark has a separated quota in the pro plan, so I just use it when I am out of the normal quota, or use it for less complicated tasks to save token.