Usage & Spend projections can prune wider retained Codex cost history

[thomaschow19]

Summary

Usage & Spend requests a narrow reporting window while the cost cache may retain a wider configured history. Under row or byte pressure, the current save path treats the requested reporting window as the retention boundary.

As a result, opening or refreshing a 7- or 30-day dashboard projection can delete completed cached rows and daily aggregates outside that projection, then narrow the persisted scan metadata. A dashboard view should extract a slice from the cache; it should not rebuild or destructively redefine the cache's retained coverage.

Expected behavior

• The configured/persisted history window remains the cache-retention authority.
• 7- and 30-day dashboard views are read projections over that retained cache.
• A requested extension beyond current retained coverage is also protected.
• Cache budgets remain best-effort for all retained in-window history.

Synthetic reproduction

1. Persist a complete cache with a wider retained window, including one older record and one recent record.
2. Set the file-byte budget below the database size.
3. Save the unchanged cache with a 30-day requested window.
4. Repeat through the full-save path with a 7-day requested window.
5. Observe that the older row and aggregate are deleted and the persisted lower coverage bound is rewritten to the narrow request.

Scope

This is a persistence-boundary bug. It is distinct from dashboard catch-up progress or the hard-coded Finish now scan scope tracked in #2861.

Related: #2823 and #2825.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 13, 2026, 5:14 PM ET / 21:14 UTC.

Summary
Keep open: the report describes potential persisted cache-history loss and has a directly linked open repair PR that explicitly owns this issue; it should be reviewed to resolution before closing the issue.

Reproducibility: unclear. the linked PR reports a synthetic reproduction against v0.49.4, but this review could not independently inspect or run the current source path because repository commands failed in the sandbox.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Share version, platform, channel/provider, and relevant config details.

Next step
An open linked PR already owns the repair, so a parallel fix job would duplicate work.

Review details

Best possible solution:

Review the linked repair against the current cache-save and budget paths, with regression coverage proving narrow projections preserve wider retained metadata and aggregates before resolving this issue.

Do we have a high-confidence way to reproduce the issue?

Unclear: the linked PR reports a synthetic reproduction against v0.49.4, but this review could not independently inspect or run the current source path because repository commands failed in the sandbox.

Is this the best way to solve the issue?

Unclear: preserving the persisted retention authority is a narrow plausible direction, but current source and the linked PR diff need review before confirming it is the best implementation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The linked PR is still draft, so closing this issue before its retention behavior and upgrade safety are reviewed could leave persisted-history loss unresolved.
• Current-main source and repository history could not be inspected because the read-only sandbox command failed.

Codex review notes: model internal, reasoning high; reviewed against daf02ae7a7a4.

Label changes

Label justifications:

• P2: Potential loss of retained historical cost rows and aggregates is a normal-priority persistence defect with a focused linked repair.
• impact:data-loss: The report describes cache saves deleting completed retained rows and daily aggregates outside a narrow dashboard projection.

Evidence reviewed

What I checked:

• Open repair owner: The provided timeline links open draft PR Preserve wider Codex history across dashboard projections #2915, whose body explicitly closes this issue and targets retained-cache coverage across dashboard projections. (81b208002789)
• Distinct prior work: The context identifies merged PR Preserve Codex cost usage window under byte pressure #2825 as addressing byte-budget protection for a requested window, while this report concerns preserving a wider persisted retention window when a narrower projection is saved. (597b0f17d1e1)
• Inspection limitation: Read-only repository inspection could not execute: the sandbox failed before producing command output (bwrap RTM_NEWADDR permission failure). Current-main source, history, VISION.md, and the maturity helper were therefore not independently inspected.

Likely related people:

• thomaschow19: Opened this issue and the currently open PR that proposes the focused retention-boundary repair. (role: reporter and linked repair author; confidence: medium; commits: 81b208002789)
• Whiteknight07: Authored the merged related byte-budget retention work referenced by the report; local feature-history inspection was unavailable. (role: adjacent prior contributor; confidence: low; commits: 597b0f17d1e1)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[nohli]

For me, usually after an update, CodexBar loses the history and only keeps the last 1-2 days or so

I believe that the tokens shown are correctly accumulated, but not the 30d costs.
I see my usage correctly in https://chatgpt.com/codex/cloud/settings/analytics#usage.

Screenshot from 10.8.:

Screenshot from 12.8.:

Screenshot from 14.8.: