I’m a ChatGPT Pro user ($200/month) and a heavy Codex user. I use Codex as a primary development environment across several long-running projects.
I recently ran into a serious combination of reliability and product-design problems that made Codex Desktop effectively unusable.
Environment:
- macOS 26.3.1
- Apple Silicon MacBook Pro
- ChatGPT Pro
- Codex CLI 0.147.0
- Codex Desktop / ChatGPT Desktop with Codex
- ~1,200 total Codex chats
- ~25.6B lifetime tokens
- Codex Desktop became unusable because of accumulated local session history
Codex Doctor reported:
- 608 active rollout files
- 25.45 GB of active rollout data
- 113 archived rollouts / 2.51 GB
- databases healthy
- no config, auth, network, Git, or installation failures
The Codex Desktop app would become extremely slow / restart itself when opening Codex.
After moving the large active session directory out of ~/.codex/sessions and starting with an almost empty active session directory, Codex Desktop immediately worked normally again.
This strongly suggests that the Desktop app is attempting to enumerate/load/process too much active session history at startup.
There was no proactive warning before the app became unusable.
Codex already has enough information to detect this because codex doctor can report active rollout count and total disk size.
The app should warn users long before this becomes a failure condition.
For example:
“Your active Codex history is unusually large:
608 active sessions
25.45 GB total
Largest sessions: 6.7 GB, 3.3 GB, 3.2 GB
Large active history may affect Codex performance.
Recommended:
- summarize and continue in a new thread
- archive old threads
- review largest sessions”
- Codex needs a built-in “Summarize and Continue” / “Compact and Archive” workflow
My largest active sessions were:
- ~6.7 GB — SuggestifAI
- ~3.35 GB — SuggestifAI
- ~3.25 GB — Klisens
These are legitimate long-running development threads, not accidental files.
For users who use Codex continuously on large projects, long-running threads naturally accumulate architecture decisions, requirements, failed approaches, TODOs, deployment knowledge, and project context.
Today there is no simple supported UX to safely convert a huge thread into a new lightweight continuation thread.
I had to manually create project handoff documents containing:
- current implementation state
- architecture
- important decisions
- known bugs
- failed approaches
- open tasks
- infrastructure/deployment information
- continuation instructions
This should be a first-class Codex feature.
For example:
“Summarize & Continue”
Codex should:
- inspect the current repository as source of truth
- summarize durable project context
- create a new lightweight continuation thread
- preserve the original thread in Archive
- allow restoring the archived thread later
The user should not have to manipulate JSONL rollout files or local state manually.
- Archive/state handling failed even though session data was valid
I attempted to archive the oversized historical sessions using the supported:
codex archive
command.
Codex reported:
Error: failed to archive session
The analysis indicated that the state database and the actual rollout paths were no longer aligned.
Important detail:
- rollout backups still existed
- rollout files were valid
- Codex Doctor reported healthy databases
- thread inventory initially agreed
- no files were intentionally deleted
Some sessions existed on disk but were not registered in the state DB, while others were registered but could not be archived.
There should be a supported repair/re-index command such as:
codex doctor --repair-sessions
or:
codex sessions reindex
that safely rebuilds session metadata from the rollout files.
Users should never need to manually move files between sessions and archived_sessions and risk desynchronizing the state database.
- Codex usage-limit/reset UX is extremely confusing
I am on the $200/month Pro plan.
Today I saw approximately 98% remaining usage and the UI offered me an available usage reset.
I clicked the reset because the product explicitly offered it.
The UI then showed 100%.
Later the same day, after running a long Codex maintenance/migration task, my General weekly usage showed only 8% remaining.
The Usage & Billing page now shows:
- General weekly usage: 8% left
- reset date: Aug 15
- GPT-5.3-Codex-Spark weekly usage: 100% left
- Credits balance: $0
The UX around the reset is unclear.
If a reset is a limited entitlement, the UI should clearly explain BEFORE applying it:
- whether unused allowance is discarded
- whether the reset starts a new weekly period
- whether it simply restores the current allowance to 100%
- whether the reset can be used again later
- how valuable the reset is
Offering a limited reset when the account still has ~98% remaining without a strong warning is extremely confusing.
A confirmation should say something like:
“You currently have 98% of your weekly allowance remaining.
Using this reset will restore your allowance to 100% and consume one available reset.
Unused allowance does not carry over.
Are you sure you want to use it now?”
- Usage should be visible while long agent jobs are running
A long Codex maintenance operation ran for more than two hours.
Users need visibility into the expected usage impact of large jobs.
At minimum, Codex should expose:
- current weekly usage %
- approximate usage consumed by the current task
- warning when a task is consuming unusually high usage
- estimated impact before running extremely large context operations
It is frustrating to pay $200/month, launch what looks like a normal Codex operation, and only later discover that a very large portion of the weekly allowance has been consumed.
Summary of requested improvements
- Warn when active session history becomes abnormally large.
- Show largest sessions and their sizes.
- Add one-click “Summarize & Continue”.
- Automatically archive the original large thread after safe handoff.
- Add supported session re-index/repair tooling.
- Prevent Desktop from eagerly processing tens of GB of inactive historical context.
- Explain reset entitlements clearly before they are consumed.
- Show real-time usage impact for long-running Codex jobs.
- Warn before a task is likely to consume a significant percentage of weekly allowance.
Codex itself is extremely capable, but the surrounding session management, storage lifecycle, reliability safeguards, and usage UX currently make heavy long-term use unnecessarily fragile.
This is particularly problematic for Pro users who rely on Codex daily as a primary development environment.
Best
Cantek
reaction on the GitHub issue itself—not only on this forum topic. Reactions on GitHub can help the developers gauge the number of affected users.