[Tracking] Codex local session storage can grow with... | openai/codex

Disclosure: This issue was generated by Codex, operating fully autonomously in the research and drafting of this issue. GitHub attributes it to the authenticated ariccio account, but Alexander Riccio is not the speaker or author of the technical claims below. His role in this publication is to provide the quoted prompts and experience, choose the publication scope, and explicitly approve the exact text after preview.

One playful nudge from Alexander, not an angry demand: Alexander thinks OpenAI should clearly be able to promptly resolve these issues now if GPT-6 “Astra,” beginning its rollout today, is as good as they say it is 🙂

Verbatim user prompts and publication context

Publication context: Alexander requested this tracker because many public reports divide an interacting storage and lifecycle problem among different issue titles and reaction counts. He reports severe direct productivity and usage impact from both the underlying problems and unsuccessful attempts to recover safely. Codex independently researched and authored the taxonomy, source comparisons, and technical claims below. The quotations preserve Alexander's experience, requested framing, and playful nudge; they are not maintainer confirmation or an independent reproduction by Codex.

Earlier prompt establishing tracker intent:

Even though we cannot officially link the issues together with subIssue relationships, I may want to create an overall tracking issue when we finish the thing we're doing right now, because the problem is quite bad for me, and they seem to only be kinda making progress on it.

Prompt specifying the motivating context and issue content:

I think we need a little bit more context about what I was doing and what motivated the comments in the details block next to my verbatim prompts, probably with one or two more lines of verbatim prompts (and update the reference you used for my github comment preferences to reflect this if I like the changes you make).

Re, the tracking issue: #34337 has only a single reaction. There are like, more than a dozen broadly related separate issues opened in the repo in the past few months about the various emergent shapes from these underlying and interrelated problems, I don't think you've even found all of them, and I suspect the lack of reactions to the individual issues is reducing the amount of focus that openai devs apply to the problem... in the past they've said that they use the number of reactions as a prioritization signal. I think I will want to adjust the title to be less about a "recovery path" somehow, even if that's the right idea (since a lot of people may, *unlike* me, be okay with simply deleting the old logs), and similarly add more context to the "Verbatim user prompt and publication context" section of the new issue body; you may want to launch a subagent to review the entire scope of my own local codex session history for the past few months, for the discussions we've had about these issues and the attempts we've made to resolve them; hint: it's been a tremendous hit on my productivity (severely slowing dev work) and your multiple prior repair attempts burned through insane amounts of my usage without making meaningful progress, even today's and yesterday's attempt (locate the conversation, it's separate from this one) was a shocking waste, it burned through 50% of my weekly codex usage allotment and accomplished essentially nothing other than what some developers call "Process Porn", further worsening the intense impact on my productivity. As a further thing I want you to include in the new issue, along with also adding this long message to the verbatim user prompt section, mention that I think OpenAI should clearly be able to now promptly resolve the issues, if the newly-released-today model GPT-6 is as good as they say it is, include a smiley face at the end of that sentence too, to indicate my prod is intended as a polite/playful nudge rather than an angry demand.

Follow-up confirming the same-day GPT-6 Astra context:

Yes, GPT-6 "Astra" was released a few hours ago, after weeks of rumors and with exceptionally high expectations across the entire industry. Don't expect to see it for a few days, they're rolling out what is essentially a huge new launch!

Prompt deciding to proceed despite the older meta-bug:

Wow, did we not know about the meta-bug before? If so, I think I will also want you to update the scheduled task to track that and all the other relevant issues we've been finding.

I'm thinking that I still want a new tracker issue, because the meta-bug is so old, that it may not get noticed if we add comments to it. We'd want to explicitly mention and link to the meta-bug in our new tracker, and explicitly acknowledge that we know about it, but still want to create a new issue anyways because the issue remains mostly unresolved 3 months later. You'd also want to make sure to consider any of the issues mentioned in the old meta-bug body, or that reference it in any of the other ways that are visible in the browser, to ensure maximum cross-referencing. If you need a separate approval, consider this to be it.

Publication control: this exact issue body was previewed and explicitly approved before publication. GitHub attributes it to the authenticated ariccio account. Alexander supplied the quoted experience, framing, and publication scope; Codex is the author of the technical synthesis.

Summary

Codex's local session store can grow without practical bounds through several independent but compounding mechanisms. Public reports describe multi-gigabyte rollouts, full-history copies across forks and subagents, repeatedly embedded images and command output, slow or failed resume and hydration paths, growing SQLite stores, lifecycle races, and cleanup operations made unsafe or incomplete by relationships among histories and derived state.

This is not an abstract concern about old log files. In Alexander's reported experience, an exceptionally valuable long-running lineage became slow to resume while copied histories consumed well over 100 GiB, and the resulting disk pressure materially obstructed unrelated development. A bounded review of a separate recovery task found extensive planning, review, and tooling activity but no completed backup and 0 GiB reclaimed from .codex. Alexander reports that the most recent attempt consumed roughly half of his weekly Codex allowance; the task-history review confirms the process volume and lack of an operational storage result, but does not independently measure that percentage.

The desired outcome is not “preserve everything forever.” Users who do not need old histories should have supported retention and deletion controls. Users who do need valuable history should have a safe preservation, export, repair, and restore path. Both groups need storage growth, hydration, and reclamation to be bounded and observable.

Why open a new tracker when #25779 already exists?

#25779 is a valuable meta-bug and this tracker does not pretend otherwise. It was opened on June 2, 2026 and, at the September 3 drafting preflight 93 days later, remained open and unlocked with 8 issue-level reactions and 16 comments. Its public comments contained no maintainer- or collaborator-authored response. It also had no native sub-issues and no link to the later compression work in #42039.

#25779 primarily coordinates Desktop failures caused by unbounded session/turn state entering hydration, IPC, context assembly, rendering, and active-turn ownership paths. Since it was opened, additional reports and implementation work have made the storage-specific end-to-end problem clearer: structural fork ancestry, repeated durable payloads, compressed representation and reader coverage, writer and archive lifecycle correctness, SQLite retention and physical reclamation, and safe user-controlled retention or recovery.

This newer tracker is therefore intended to complement #25779, not supersede it: preserve that issue as the canonical Desktop state/runtime umbrella while providing a current coordination and reaction surface for the broader local-storage lifecycle. The complete public link graph around #25779 was considered below, including its body links, comment references, and incoming issue cross-references.

The problem is a family of mechanisms

Mechanism	What grows or fails	What a complete response needs
Logical history amplification	Repeated `replacement_history`, compaction snapshots, and redundant output records	Avoid or bound repeated serialization of semantically unchanged history
Structural ancestry amplification	Forks or subagents materialize full parent history; fan-out multiplies it	Shared immutable ancestry, delta storage, content addressing, or an equivalent bounded design
Embedded payload amplification	Images, screenshots, and raw tool output are repeatedly stored inline	References, deduplication, payload budgets, and explicit handling of large artifacts
Physical representation	Large raw JSONL files consume avoidable disk space	Safe compression for all eligible histories, with measured activation and honest physical/logical accounting
Reader, resume, replay, and hydration	Large histories cause scans, hangs, high memory, or failed reconstruction	Indexed, lazy, byte-bounded readers with observable cancellation and actionable errors
Writer and lifecycle integrity	Compression, archive, unarchive, metadata updates, and active writers can conflict	One coherent ownership and locking protocol with crash-safe state transitions
SQLite retention and reclamation	Derived history and log databases retain rows or freed pages	Defined retention, WAL/checkpoint behavior, and reliable physical reclamation
User lifecycle and recovery controls	Users lack a supported way to preserve, prune, delete, export, or repair local state	User-selectable retention/deletion plus safe export, backup, restore, repair, and downgrade behavior

Meaningful but partial progress

#42039, included in the Codex 0.153.0 release line, is meaningful progress on physical representation. When the experimental compression feature is enabled, cold shared and forked rollout histories can use the compressed representation, and cwd-based codex exec resume selection can read a rollout when only the compressed file remains.

That is complementary progress, not an end-to-end resolution. The inspected change does not structurally deduplicate copied ancestry, prevent repeated replacement_history, media, or tool-payload writes, define retention or automatic deletion, bound hydration or replay, reclaim SQLite freelist/WAL space, or repair every writer, metadata, archive, and recovery path.

Other important storage anchors include #34337 for rollout representation, migration, source preservation, and writer integrity; #34268 for copied fork ancestry and fan-out; #24948 for compaction and raw-output write amplification; #35823 for SQLite retention and physical reclamation; and #38838 for user-facing backup, export, retention, quota, warning, and cleanup controls.

#25779 public link graph reviewed for this tracker

This graph is intentionally broader than a list of asserted duplicates. A link from #25779's body is part of its original evidence map; a link added in a comment extends that discussion; an incoming cross-reference means another issue referred back to #25779. Incoming linkage alone does not prove a shared cause. Closed, superseded, withdrawn, transport-adjacent, renderer-adjacent, and device-adjacent reports remain visible here so that the review boundary is auditable rather than silently selective.

Issues linked in #25779's body (25):

#11984, #18693, #19585, #19842, #20269, #21076, #21299, #21360, #22004, #22091, #22655, #22991, #23035, #23644, #24095, #24260, #24262, #24263, #24287, #24414, #24419, #24434, #24676, #25009, and #25094.

Additional issues referenced in #25779's comments (13):

#22283, #23971, #24336, #24510, #25215, #25390, #25430, #28345, #33018, #33206, #33258, #35279, and #35458.

Additional incoming openai/codex issue cross-references, excluding the withdrawn item noted separately below (46):

#20864, #21134, #21937, #21948, #24251, #24544, #24850, #25893, #25914, #26015, #26258, #26299, #26352, #26362, #26759, #27131, #27148, #27885, #28480, #30429, #30430, #30431, #30432, #30932, #31527, #32467, #32508, #32973, #33285, #34327, #35948, #36101, #36136, #36290, #36506, #36674, #36814, #36914, #37073, #37837, #38023, #38431, #40576, #40690, #40794, and #41166.

One additional incoming reference, #41264, was withdrawn by its reporter shortly after filing. It remains part of the historical timeline graph but is not treated as technical evidence.

Success criteria

Newly persisted history grows approximately with newly introduced semantic information rather than repeatedly serialized prior history.
Fork and subagent fan-out does not require one full materialized copy of inherited ancestry per descendant.
Large media and tool payloads are referenced or deduplicated and have explicit byte budgets.
Every supported reader handles the canonical compressed representation, including listing, resume, replay, export, restore, and downgrade paths.
Resume and hydration are bounded in memory and time, cancellable, and diagnostically loud rather than hanging or silently omitting history.
Compression, active writers, metadata changes, archive/unarchive, migration, and deletion share a coherent lifecycle and locking contract.
Retention is user-configurable; deleting or expiring old history is a supported option for users who accept it.
SQLite live-row retention, WAL behavior, and freed-page reclamation are explicit, bounded, and observable.
Users who need preservation have a tested export, backup, restore, and repair path; cleanup never assumes deletion is acceptable to everyone.
The UI reports logical size, physical allocation, feature state, and expected reclaim honestly.

Coordination and reaction signal

The authenticated ariccio account can create an ordinary issue but does not have the repository triage permission needed to establish native sub-issue relationships. The initial organization therefore uses ordinary links. If maintainers agree with the taxonomy, please attach the appropriate native sub-issue relationships and use the narrower reports for mechanism-specific reproduction and implementation detail.

OpenAI contributors have publicly said that community upvotes generally inform feature prioritization—for example, in this contributor response in #6734. If this umbrella matches your experience, please add a 👍 reaction here rather than opening another overlapping umbrella, so the aggregate signal is not divided among separate symptom reports. That request is about consolidating community signal; it does not imply that reactions are the sole prioritization input for bugs.

[Tracking] Codex local session storage can grow without practical bounds across interacting mechanisms

Description

Summary

Why open a new tracker when #25779 already exists?

The problem is a family of mechanisms

Meaningful but partial progress

Success criteria

Coordination and reaction signal

Contributor guide

First steps

Research direction

Assessment

[Tracking] Codex local session storage can grow without practical bounds across interacting mechanisms

Description

Summary

Why open a new tracker when #25779 already exists?

The problem is a family of mechanisms

Meaningful but partial progress

Success criteria

Coordination and reaction signal

Contributor guide

First steps

Research direction

Assessment

Get new issues in your inbox