Regression after Codex App update: existing Windows threads become unrecoverable with context window exceeded

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

26.901.51231

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After updating the Codex App, many of my previously working saved threads became unusable.

When I open an affected existing thread and try to continue it, Codex immediately returns:

"Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying."

This did not happen to these threads before the update.

The problem affects many existing threads rather than a single unusually long conversation. New threads can still work, but historical project threads that were usable before the update can no longer be continued.

I inspected the local Codex task data to understand whether the history itself had been corrupted.

Current findings:

• 55 local Codex tasks in total
• 33 tasks have tokens_used equal to or greater than the current context limit
• 16 tasks are marked memory_mode = polluted
• database integrity checks pass
• the original conversation messages, tool records, and task contents are still readable locally
• most affected tasks were originally created with an older Codex version

This suggests that the underlying conversation history has not been lost. The issue appears to occur when the newer Codex App restores or migrates the context/compaction state of older threads.

It looks like some old threads may contain a large cumulative tokens_used value or previous compaction state. After the update, that state may be interpreted as the current active context, causing the thread to immediately exceed the context window.

The especially problematic part is that the affected thread cannot recover itself. Attempts to continue the conversation or trigger context recovery/compaction still result in context_window_exceeded.

Expected behavior:

Existing threads that worked before an application update should remain recoverable after upgrading.

If an older thread exceeds the current context window, Codex should be able to safely reconstruct or re-compact its historical context rather than permanently blocking the thread.

Starting a new thread is not an adequate workaround for long-running coding projects because the original thread contains substantial project context, implementation decisions, debugging history, and tool interactions.

Reconstructing this context in new threads requires Codex to re-read the project and rediscover previous decisions, resulting in substantial additional usage.

This regression has also consumed a substantial amount of my Codex usage allowance.

Because many historical threads can no longer be resumed, I have had to repeatedly ask Codex to re-read project files, reconstruct prior implementation decisions, reproduce debugging context, and attempt thread recovery.

These repeated recovery attempts have consumed a significant portion of my available Codex quota, despite not representing new productive work. In practice, I am spending a considerable amount of my Codex allowance just trying to recover from a regression that appeared after the application update.

Starting a new thread is therefore not a cost-free workaround. For long-running projects, it forces Codex to rebuild context that had already been processed in the original thread.

The practical impact for me is therefore twofold: loss of access to long-running project context, and significant additional Codex quota consumption caused by attempts to work around the regression.

If possible, I would also appreciate guidance on whether usage consumed while troubleshooting this regression can be reviewed, since a substantial amount of my Codex allowance has already been spent attempting to recover threads that worked before the update.

Importantly, the historical data still appears to exist locally, so I would strongly prefer a migration or recovery mechanism that restores affected threads without destroying their existing history.

I can provide sanitized logs, affected thread IDs, local database metadata, rollout JSONL files, and screenshots if that would help diagnose the migration/compaction issue.

Possibly related to #44584, although in my case this affects a large number of existing threads after the update rather than only one long-running task.

What steps can reproduce the bug?

1. Open the Codex App on Windows.

2. Open an existing saved thread that was created before the recent Codex App update.

3. Try to continue the conversation by sending a new message.

4. Codex immediately returns:

"Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying."

5. Retrying the message produces the same error.

6. Attempts to recover or compact the affected thread also fail with context_window_exceeded.

7. The same issue occurs across many previously working historical threads, while newly created threads can still work normally.

The issue is therefore reproducible by reopening and attempting to continue affected pre-update threads.

Additional observations from local task data:

• 55 local Codex tasks in total
• 33 tasks have tokens_used equal to or greater than the current context limit
• 16 tasks are marked memory_mode = polluted
• database integrity checks pass
• original conversation history and tool records remain readable locally

What is the expected behavior?

No response

Additional information

This regression has had a significant impact on my workflow.

Many of the affected threads contain long-running project context, implementation decisions, debugging history, and prior tool interactions.

Because these threads can no longer be resumed, I have had to repeatedly ask Codex to re-read project files, reconstruct prior decisions, reproduce debugging context, and attempt recovery.

These recovery attempts have consumed a substantial amount of my available Codex usage allowance, even though they do not represent new productive work.

In practice, I am spending a considerable portion of my Codex quota just trying to recover from a regression that appeared after the application update.

Starting a new thread is therefore not a cost-free workaround. For long-running projects, it forces Codex to rebuild context that had already been processed before.

If possible, I would also appreciate guidance on whether usage consumed while repeatedly troubleshooting this regression can be reviewed, since a substantial amount of my Codex allowance has already been spent attempting to recover threads that worked before the update.

Current environment:

Codex App version: 26.901.51231
Subscription: ChatGPT Plus
Platform: Microsoft Windows NT 10.0.26200.0 x64

Possibly related to #44584, although in my case the issue affects a large number of existing threads rather than only one long-running task.

I can provide sanitized logs, affected thread IDs, local database metadata, rollout JSONL files, screenshots, and additional diagnostics if useful.

Start by reproducing the failure on Windows with an existing pre-update thread, then inspect the local task data and migration or compaction state described in the report. Compare affected historical threads with newly created threads, including tokens_used and memory_mode values. Done means previously working threads can be reopened and continued, with recovery or re-compaction succeeding without losing history.