config.toml context window settings are not respected

What happened?

The context-related settings in config.toml do not appear to take effect. I tried configuring Codex from:

C:\Users\12768\.codex\config.toml

Relevant settings:

model = "gpt-5.5"
model_reasoning_effort = "high"
model_context_window = 960000
model_auto_compact_token_limit = 800000

After setting a large context window, for example around 1M, Codex still automatically reports/uses about 258k instead. This makes it impossible to control the effective context window from the config file.

Expected behavior

model_context_window and model_auto_compact_token_limit should be honored, or Codex should report a clear validation/error message if the configured value exceeds the supported model/client limit.

Actual behavior

The configured value is silently reduced/ignored. For example, setting approximately 1M results in Codex automatically changing/using about 258k.

Environment

OS: Windows
Config path: C:\Users\12768\.codex\config.toml
Model configured: gpt-5.5

Why this matters

Users cannot reliably control context behavior through config.toml, and the silent conversion makes it difficult to understand whether the setting is unsupported, capped by the model, capped by the client, or being parsed incorrectly.

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

Codex Pro GPT-5.4 long context regressed: ~672k worked Apr 22, ~290k fails Apr 23 #19142
Codex CLI freezes near auto-compaction threshold and drifts with very large context windows #19116
TUI runs out of context with gpt-5.5 despite auto-compact config #19183

Powered by Codex Action

gpt 5.5 doesn't have 1m context window with codex :(

I can reproduce/confirm this on Codex Desktop for macOS as well, and it looks like the config is being loaded but then clamped by model metadata rather than ignored.

Environment I checked:

Codex.app: 26.422.20832
Bundled CLI: codex-cli 0.124.0-alpha.2
Model: gpt-5.5
Config included:

model = "gpt-5.5"
model_context_window = 1050000
model_auto_compact_token_limit = 900000

Observed model metadata from the installed app:

model	context_window	max_context_window	effective_context_window_percent
`gpt-5.4`	272000	1000000	95
`gpt-5.5`	272000	272000	95
`crest-alpha`	272000	272000	95

The relevant source path appears to be with_config_overrides, which clamps the configured context window to max_context_window:

codex/codex-rs/models-manager/src/model_info.rs

Lines 29 to 36 in 3f8c06e

    
           if let Some(context_window) = config.model_context_window { 
        
               model.context_window = Some( 
        
                   model 
        
                       .max_context_window 
        
                       .map_or(context_window, |max_context_window| { 
        
                           context_window.min(max_context_window) 
        
                       }), 
        
               );

So for gpt-5.5, model_context_window = 1050000 becomes min(1050000, 272000) = 272000. Then the effective context shown/used is further reduced by effective_context_window_percent = 95, which explains the ~258400 number.

The struct docs also describe max_context_window as the maximum allowed for config overrides:

codex/codex-rs/protocol/src/openai_models.rs

Lines 279 to 285 in 3f8c06e

    
               pub context_window: Option<i64>, 
        
               /// Maximum context window allowed for config overrides. 
        
               #[serde(default, skip_serializing_if = "Option::is_none")] 
        
               pub max_context_window: Option<i64>, 
        
               /// Token threshold for automatic compaction. When omitted, core derives it 
        
               /// from `context_window` (90%). When provided, core clamps it to 90% of the 
        
               /// context window when available.

And auto-compact is similarly capped to 90% of the resolved context window:

codex/codex-rs/protocol/src/openai_models.rs

Lines 310 to 318 in 3f8c06e

    
           pub fn auto_compact_token_limit(&self) -> Option<i64> { 
        
               let context_limit = self 
        
                   .resolved_context_window() 
        
                   .map(|context_window| (context_window * 9) / 10); 
        
               let config_limit = self.auto_compact_token_limit; 
        
               if let Some(context_limit) = context_limit { 
        
                   return Some( 
        
                       config_limit.map_or(context_limit, |limit| std::cmp::min(limit, context_limit)), 
        
                   );

This makes the current behavior understandable but surprising: gpt-5.4 can use 1M because its catalog entry advertises max_context_window = 1000000; gpt-5.5 cannot because its catalog entry advertises max_context_window = 272000.

Expected improvement: if this is intentional because gpt-5.5 does not currently support 1M in Codex, Codex should surface a clear warning/status message when config values are clamped, e.g. model_context_window=1050000 was reduced to 272000 because gpt-5.5 max_context_window is 272000. If gpt-5.5 is supposed to support 1M, then the model catalog entry likely needs to advertise the larger max_context_window.

#19208 (comment)
#19208 (comment)
It sounds expected, but I am unhappy with that...

setting to 400000 is not working as well

This looks like a real joke. 258,000 is not a thing that you can rely on for heavy-duty work, complex or long projects or planning It's absolutely disappointing.

1M being available on 5.5 would be nice but the actual bug here is it's supposed to be 400k (which is more tolerable at least).

So currently you can have 5.4 @ 1M or 5.5 @ 272k, but not 5.5 @ 1M or even the advertised 5.5 @ 400k.

258k in 2026 is a real nonsense

@etraut-openai

@etraut-openai thanks for your response, however:

It's misleading to refer to "sum of input and output" as the "context window". When people talk about context window they mean input - that's what's displayed in codex/claude code as context usage meter, it's the model_context_window in config.toml, when we talk about 1M context that means input, etc.. Summing input & output to get a larger number seems like marketing so let's not do that.
GPT 5.5 is showing double the scores for long context retrieval than 5.4 so 1M is absolutely feasible in this model vs 5.4.
My understanding is 1M will be offered on API/enterprise just not on subscription, so again seems like it's viable.
Auto-compaction part-way through long-running tasks is absolutely not better than long context - compaction loses all the detail of what's been done so far and that is still to do (even if there is an on-disk plan to follow, which isn't always the case). At best the model has to burn more tokens trying to figure out where it was up to, and at worst it makes mistakes as a result of the lost context.

So we have a choice 5.4 which is bad at long context but can do 1M, or 5.5 which is good at long context but it's not available. How does this make sense?

The overall result is that (at least on subscription plans) codex + gpt 5.5 can't compete with Opus 4.6/4.7 which are 1M by default now. This doesn't seem like a good outcome for OpenAI.

@mark-99

@mark-99, thanks for the feedback.

There are a couple of different concepts that are getting conflated here, which is understandable because we're sometimes sloppy about using the term "context window" to mean different things in different contexts. When we talk about the context window capabilities of a model, we're talking about the total context that it supports.

When a model is used in the context of Codex (or any other agent harness), that total context window needs to be managed to avoid overflow. That leads to the need to distinguish between input and output token capacities.

There are many factors that go into decisions about which context window sizes to support — including model capabilities, hardware capacity, hosting costs, user needs, etc.

Someone has opened a feature request: #19464. We'll use that to gather additional feedback and upvotes on this topic. Let's keep the discussion going there.

@etraut-openai

@etraut-openai Thanks for the clarification.

I don’t want to get into the side arguments here, but I do want to emphasize the main point: larger configurable context is one of the most important features for real-world Codex usage right now.

Most serious competitors already support much larger context windows, and GPT-5.5 appears to be a model that could benefit from that capability. It is reasonable to keep the current 258K auto-compaction behavior as the default, but users should still have the freedom to override it when their workflow requires it.

There is no single setting that works for every user and every project. For large codebases, tightly connected files, long debugging sessions, migrations, planning, and multi-step development work, losing context through compaction can be a major problem. Auto-compaction is useful, but it is not a replacement for true long context. It can make the model lose important details, drift from the task, or force the user to spend extra time re-explaining what was already known.

Please consider bringing back support for a larger optional context window, especially for users who explicitly configure it and understand the tradeoffs. The default can stay conservative, but advanced users should not be blocked from choosing the larger context window when they need it.

I hope this feature returns soon.

@litaotju

(this message applies only to api key users who want long contexts)

FYI @litaotju you can use a custom models.json file to fix your issue. In config.toml, set model_catalog_json=<path to your models.json>. Copy the contents of ~/.codex/models_cache.json into that your custom models.json. For gpt-5.5, set "max_context_window": 1000000. I tested long contexts with this solution, it works as you'd expect.

Using a custom models.json is handy. I also use it to clean up my model picker of models I don't use.

(this message applies only to api key users who want long contexts)

FYI @litaotju you can use a custom models.json file to fix your issue. In config.toml, set model_catalog_json=<path to your models.json>. Copy the contents of ~/.codex/models_cache.json into that your custom models.json. For gpt-5.5, set "max_context_window": 1000000. I tested long contexts with this solution, it works as you'd expect.

Using a custom models.json is handy. I also use it to clean up my model picker of models I don't use.

Tried it - but it only leads to that codex shows "context window out of bounds" eventually
(pro subscription, not api)

@astandrik

@astandrik Yep. Looks like there's a server-side gate for long context.

So, is the subscription plan useful?

…

---- Replied Message ---- From ***@***.***> Date 04/25/2026 16:15 To ***@***.***> Cc ***@***.***>***@***.***> Subject Re: [openai/codex] config.toml context window settings are not respected (Issue #19185) miraclebakelaser left a comment (openai/codex#19185) @astandrik Yep. Looks like there's a server-side gate for long context. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

So, is the subscription plan useful?
…

It doesn't matter which subscription you have, or why you think having a different subscription makes any difference. In Codex, the only difference between subscriptions is in rate limits. Nothing else.

@MeXenon

@MeXenon they are likely referring to the fact that enterprise/API gets 1M and subscription does not.

yes, I am in pro subscription but no 1m ,pity,

…

---- Replied Message ---- From ***@***.***> Date 04/25/2026 19:42 To ***@***.***> Cc ***@***.***>***@***.***> Subject Re: [openai/codex] config.toml context window settings are not respected (Issue #19185) mark-99 left a comment (openai/codex#19185) @MeXenon they are likely referring to the fact that enterprise/API gets 1M and subscription does not. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

This limitation is seriously damaging real workflows.

258K is not enough for serious coding work on medium-to-large codebases. Debugging, planning, and building connected features all suffer badly :(

Please stop forcing one conservative default on everyone. This feels stubborn and dismissive of real user needs. Bring back the option for larger context windows.

@bolinfest

cc @bolinfest @aibrahim-oai @jif-oai @pakrym-oai

Please take the conversation to #19464.

Navigation Menu

Repository navigation

config.toml context window settings are not respected #19185

What happened?

Expected behavior

Actual behavior

Environment

Why this matters

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	if let Some(context_window) = config.model_context_window {
	model.context_window = Some(
	model
	.max_context_window
	.map_or(context_window, \|max_context_window\| {
	context_window.min(max_context_window)
	}),
	);

	pub context_window: Option<i64>,
	/// Maximum context window allowed for config overrides.
	#[serde(default, skip_serializing_if = "Option::is_none")]
	pub max_context_window: Option<i64>,
	/// Token threshold for automatic compaction. When omitted, core derives it
	/// from `context_window` (90%). When provided, core clamps it to 90% of the
	/// context window when available.

	pub fn auto_compact_token_limit(&self) -> Option<i64> {
	let context_limit = self
	.resolved_context_window()
	.map(\|context_window\| (context_window * 9) / 10);
	let config_limit = self.auto_compact_token_limit;
	if let Some(context_limit) = context_limit {
	return Some(
	config_limit.map_or(context_limit, \|limit\| std::cmp::min(limit, context_limit)),
	);

config.toml context window settings are not respected #19185

Description

What happened?

Expected behavior

Actual behavior

Environment

Why this matters

Activity

github-actions commented on Apr 23, 2026

joshua-angulo commented on Apr 23, 2026

litaotju commented on Apr 23, 2026

cccat6 commented on Apr 23, 2026

drixs2050 commented on Apr 24, 2026

MeXenon commented on Apr 24, 2026

mark-99 commented on Apr 24, 2026

astandrik commented on Apr 24, 2026

4 remaining items

mark-99 commented on Apr 25, 2026

etraut-openai commented on Apr 25, 2026

MeXenon commented on Apr 25, 2026

miraclebakelaser commented on Apr 25, 2026

astandrik commented on Apr 25, 2026

miraclebakelaser commented on Apr 25, 2026

kkellyoffical commented on Apr 25, 2026

MeXenon commented on Apr 25, 2026

mark-99 commented on Apr 25, 2026

kkellyoffical commented on Apr 25, 2026

MeXenon commented on Apr 25, 2026

foreverpiano commented on Apr 27, 2026

etraut-openai commented on Apr 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions