Codex's 1M Context Window Is a Model Capability, Not a Config Hack

Recently, I've seen a lot of people discussing Codex's 1M context window, and my first reaction was the same: I need to turn this on.

For those who usually just ask AI to write a function or modify a SQL query, a few hundred thousand tokens of context might be enough. But if you're really using Codex for project-level development, especially for Java / Spring Boot projects that often have dozens of modules and hundreds of classes, context size is quite important.

I used to frequently encounter a situation: just after getting Codex to understand the project architecture, after continuing to modify a few more files, the previously analyzed content would start getting compressed. If the conversation continued, it would even re-search code it had already looked at.

So after seeing the 1M context, I was ready to configure it for Codex directly.

Unexpectedly, I stepped on a landmine right at the first step.

1. The 1M Configuration Found Online Directly Prevented Codex from Starting

The first configuration method I found was very simple, saying to add the following to Codex's config.toml:

model_context_window = 1000000
model_auto_compact_token_limit = 900000

One controls the context window, the other controls when to start automatic compression.

It looked quite reasonable.

My thinking at the time was also simple: since the maximum support is 1 million tokens, set the context to 1000000, then let Codex auto-compact around 900,000, theoretically leaving some space for model output.

So I directly opened the configuration:

vim ~/.codex/config.toml

Added the config, saved, and re-executed:

codex

Then Codex didn't start and directly gave me an error:

Error loading config.toml: invalid type: integer `1000000`, expected a boolean
in `features`

When I saw this error, my first reaction was that the new version of Codex didn't support the value 1000000.

Later, upon closer inspection, I realized the real key was this last line:

expected a boolean
in `features`

In other words, Codex treated my configured 1000000 as a configuration item under [features], and the values inside features should be:

true

or:

false

As a result, I stuffed an integer 1000000 in there, and the configuration parsing naturally failed immediately.

This is also a pitfall that TOML configuration files are particularly prone to.

2. Why Did Codex Think Two Lines of Config Belonged to features?

The problem actually lies in the structure of TOML.

Assume the original configuration was something like:

model = "gpt-5.6-sol"

[features]
some_feature = true

If you continue adding after [features]:

model_context_window = 1000000
model_auto_compact_token_limit = 900000

The final result is effectively equivalent to:

model = "gpt-5.6-sol"

[features]
some_feature = true
model_context_window = 1000000
model_auto_compact_token_limit = 900000

When Codex parses this, it naturally thinks:

model_context_window is a feature.

And a feature should be a boolean value.

Thus:

model_context_window = 1000000

will produce:

expected a boolean

This problem isn't directly related to whether the number is 1000000.

If you change it to:

model_context_window = 500000

It will report the same error.

Because the error is in the configuration level, not the number size.

If a certain version does support these root-level configuration items, they should at least be placed before [features], for example:

model = "xxx"

model_context_window = 1000000
model_auto_compact_token_limit = 900000

[features]
some_feature = true

But after tinkering here, I discovered a second problem: For the new version of Codex, you can't simply force the configuration by following old online tutorials.

3. Don't Rush to Configure; The First Thing Should Be Checking the Codex Version

I re-entered Codex and then executed:

/status

The information I got was:

OpenAI Codex (v0.145.0)

Model:              gpt-5.6-sol
                    (reasoning low, summaries auto)

Directory:          ~/.config/clash

Permissions:        Workspace (Ask for approval)

Collaboration mode: Default

This step is actually very important.

Because now, searching for "Codex 1M context configuration" online yields many articles, posts, and configuration examples from different times.

The problem is that the Codex CLI updates very quickly.

What you see someone else could use a few months ago:

xxx = true

or:

model_context_window = 1000000

doesn't mean the version you have installed now still needs to be configured that way.

So in the future, when encountering Codex configuration issues, I suggest the first step should never be copying a config.toml from the internet.

First execute:

codex --version

Then enter Codex and check:

/status

First figure out three things:

What version is the Codex CLI, what model is currently in use, and what plan is the current account on.

If the versions don't match, the reference value of the subsequent tutorial is at least discounted.

4. What You Really Need to Understand About 1M Context is "Model Capability"

This is also where my initial understanding was off.

The so-called Codex supporting 1M context easily leads people to understand it as:

Codex has a hidden switch; turning it on changes the context from a few hundred thousand to 1 million.

In reality, it can't be understood so simply.

The context window is first and foremost a model capability.

That is to say, the core factor that truly determines whether you can get an ultra-long context is what model Codex is currently using for you and whether the product side has opened the corresponding capability for this model.

For example, my current /status shows:

Model: gpt-5.6-sol

Then the first thing to confirm isn't:

"How do I force it to change to 1000000?"

But should be:

"What context size does this current model actually support in Codex, and how does the current version of Codex manage it?"

These two questions are completely different matters.

The new version of Codex increasingly tends to automatically manage context based on model capabilities and product strategy, including when to summarize, when to compact, and which file contents to retain, rather than letting users casually write a number in the configuration file and truly alter the model's capability.

In other words:

model_context_window = 1000000

Even if a certain version allows this, it doesn't mean you can "hack" a model that originally only supports a smaller window into 1M.

A configuration file is not GPU overclocking.

What the model itself supports is the foundation.

5. How to Determine What Model You Are Actually Using?

The simplest method is to enter Codex:

codex

Then execute:

/status

Like mine shows:

Model: gpt-5.6-sol (reasoning low, summaries auto)

This actually reveals two other pieces of information.

One is:

reasoning low

indicating the current reasoning intensity is low.

The other is:

summaries auto

indicating that Codex itself is automatically managing conversation and context summaries.

This is also why I increasingly advise against casually modifying some parameters from unknown sources just to pursue that "1M" number.

For Agent-type programming tools, "the model supports a maximum of 1M tokens" and "stuffing all 1M tokens completely and unaltered into every task" are two completely different concepts.

Codex searches code, reads files, executes commands, re-reads modified files, and maintains task state.

What's truly important is whether it can continuously maintain an understanding of the project throughout a long task, not whether the status bar shows a pretty:

1,000,000 tokens

6. Another Practical Issue: 1M Context Is Not a Free Lunch

This time, there was another piece of information in my /status that was particularly eye-catching:

Weekly limit: 17% left

That is to say, my Codex quota for this week was already down to 17%.

Moreover, upon startup, Codex had already proactively warned:

Heads up, you have less than 25% of your weekly limit left.

At this point, mindlessly pursuing ultra-long context requires considering a very practical problem: quota consumption.

Suppose you just ask Codex to:

Help me modify the parameter validation for this Controller.

It might only need to look at the Controller, Service, DTO, and a small amount of related code.

For this kind of task, there's absolutely no need to maintain hundreds of thousands or even millions of tokens of project context in the current task.

What truly suits long contexts are other types of tasks, like:

Analyze the entire Spring Boot project's permission system, then transform RBAC to support data permissions;

or:

Sort through the entire payment project, from Controller to MQ, Redis, database, and find the problem where payment is successful but the order status hasn't been updated;

another example:

Analyze an old project with hundreds of thousands of lines of code, propose a module splitting plan, and complete the refactoring in stages.

This kind of task requires maintaining relationships across dozens or even hundreds of files, where the value of long context truly manifests.

So my attitude towards 1M has now changed from:

"Must turn it on."

to:

"Use it when needed."

7. If You Also Encounter expected a boolean, How to Recover?

If Codex now cannot start because of modifying config.toml, you can first execute:

cat ~/.codex/config.toml

Focus on finding:

[features]

Check if configurations like the following were written after it:

model_context_window = 1000000
model_auto_compact_token_limit = 900000

If so, first delete or comment out these two lines:

# model_context_window = 1000000
# model_auto_compact_token_limit = 900000

After saving, re-execute:

codex

If it can enter normally, then execute:

/status

Confirm the Codex version and current model.

You can also execute in the terminal:

codex --help

See what parameters the current version actually exposes.

This is much more reliable than directly copying configurations from the internet.

8. Another Easily Overlooked Point: Where Exactly Is the Configuration File?

In most cases, the Codex CLI uses:

~/.codex/config.toml

So you can directly:

cat ~/.codex/config.toml

or:

vim ~/.codex/config.toml

However, don't see the terminal's current directory as:

~/.config/clash

and assume the configuration file is at:

~/.config/clash/config.toml

These are two different things.

The Directory: in /status:

Directory: ~/.config/clash

represents the project directory Codex is currently working in.

For example, if you are in:

cd ~/.config/clash

and then execute:

codex

Then Codex will treat the Clash configuration directory as the current Workspace.

This is not the same concept as Codex's own global configuration file.

9. Why Is 1M Context Indeed Attractive for Java Projects?

Despite all the pitfalls mentioned earlier, I still believe long context is very valuable for programmers, especially Java backend developers.

A slightly mature Spring Boot project can easily have:

Controller
Service
ServiceImpl
Mapper
Entity
DTO
VO
MQ Consumer
Redis
XXL-JOB
Feign
Config
Util
SQL
Nacos Config

A single business chain might span over a dozen files.

The most annoying thing about traditional AI programming is:

You just finished explaining A, and it forgot B;

Just after adding B, the previous database structure got squeezed out.

In the end, the human becomes the AI's "context porter":

"Remember that UserService from earlier?"

"Combine this with the table structure I sent you before."

"Not this method, the previous payment callback one."

This kind of development experience is actually very tiring.

What long context truly solves is not "letting AI read 1 million words at once," but giving the Agent more space to maintain, during a development task lasting an hour or two or even longer:

Project structure + Read code + User requirements + Modification records + Test results + Error logs + Follow-up plans.

This is where 1M is truly meaningful for Codex.

10. After All This Tinkering, I'm Actually in No Rush to Manually Turn on 1M

The biggest gain this time wasn't finally finding some mysterious parameter, but figuring out Codex's context mechanism.

If you are using a new version of Codex, especially if the version has reached:

Codex v0.145.0

such a relatively new version, I suggest not directly copying:

model_context_window = 1000000

just because you see someone post it online.

The correct order should be:

First check:

codex --version

Then check:

/status

Confirm the current model, then decide whether manual configuration is still needed based on the current Codex version and the model's actual supported capabilities.

If startup directly shows:

invalid type: integer `1000000`, expected a boolean
in `features`

Don't immediately suspect Codex is broken.

Nine times out of ten, it's just that the TOML configuration level was placed incorrectly.

Finally, let me share an increasingly obvious feeling I have about using Codex now:

Of course, the larger the context, the more comfortable it is, but context size is not the entirety of the Agent programming experience.

Previously, when we used ChatGPT to write code, the core problem was:

"How much code can be fed in at once?"

Now, using an Agent like Codex, the problem is slowly becoming:

"Can it find the code it really needs to look at by itself, and not lose key context throughout the entire task?"

Even if a model supports 1M, if it reads a large amount of irrelevant code every time, it's still slow and wastes quota.

Conversely, if Codex can accurately find the entire call chain of Controller → Service → Mapper → SQL → Configuration files, maybe a few hundred thousand context is already enough.

So 1M is worth looking forward to, but there's really no need to force it on just for the "1000000" in the status bar.

Especially like me this time, before even experiencing 1M, I first successfully crashed the Codex configuration file.

I guess I've stepped on this landmine for everyone else.

If you've also been tinkering with Codex recently and encounter a config.toml error, the first thing is not to continue copying new configurations, but to first check your own Codex version.

AI programming tools update too fast; often, the tutorial isn't wrong, it's just expired.