Bug
On OpenUsage 0.7.11, Codex's menu-bar quota can remain stale indefinitely when a large local token-history archive takes longer than the 120-second provider refresh deadline. Logs repeatedly show codex timed out after 120s after a previously successful refresh.
CodexProvider.probe obtains the live usage response, then awaits pricing plus native Codex, pi, and OpenCode scans before returning the snapshot. The local work therefore prevents publication of otherwise available quota.
Proposed fix
Bound the time spent waiting for local history without cancelling and restarting the cold scan on every quota refresh. Retain a single background scan, preserve previous history, and collect its result on a subsequent refresh. Show the existing provider warning while history is pending. Keep authentication and network failure behavior unchanged.
A focused candidate is in #1222, which the contribution-policy bot closed because I had not obtained an approved issue first. Please review the scope and, if acceptable, approve and assign this issue to @sahiinthehood so that PR can be reopened. The latest candidate is 6d26110 on fix/codex-quota-refresh. Cold history completed and persisted successfully. The optimized warm-cache relaunch published quota and history together in 4.65 seconds with no warning, then settled to about 0.1% CPU. Full suite: 1,318 XCTest cases, 3 live-test skips, zero failures, plus 3 Swift Testing checks. The closed PR ref is still at the initial commit; its description links the latest branch until approved reopening.
Reproduction
- Have a sufficiently large Codex session archive and a cold local parse cache.
- Enable Codex and refresh.
- Observe repeated provider-deadline failures and an unchanged menu-bar quota despite valid authentication.
Expected: local-history work should not prevent live quota updates, and history should eventually finish without overlapping or repeatedly restarting scans.
No credentials or conversation data are included in this report.
Bug
On OpenUsage 0.7.11, Codex's menu-bar quota can remain stale indefinitely when a large local token-history archive takes longer than the 120-second provider refresh deadline. Logs repeatedly show
codex timed out after 120safter a previously successful refresh.CodexProvider.probeobtains the live usage response, then awaits pricing plus native Codex, pi, and OpenCode scans before returning the snapshot. The local work therefore prevents publication of otherwise available quota.Proposed fix
Bound the time spent waiting for local history without cancelling and restarting the cold scan on every quota refresh. Retain a single background scan, preserve previous history, and collect its result on a subsequent refresh. Show the existing provider warning while history is pending. Keep authentication and network failure behavior unchanged.
A focused candidate is in #1222, which the contribution-policy bot closed because I had not obtained an approved issue first. Please review the scope and, if acceptable, approve and assign this issue to @sahiinthehood so that PR can be reopened. The latest candidate is 6d26110 on fix/codex-quota-refresh. Cold history completed and persisted successfully. The optimized warm-cache relaunch published quota and history together in 4.65 seconds with no warning, then settled to about 0.1% CPU. Full suite: 1,318 XCTest cases, 3 live-test skips, zero failures, plus 3 Swift Testing checks. The closed PR ref is still at the initial commit; its description links the latest branch until approved reopening.
Reproduction
Expected: local-history work should not prevent live quota updates, and history should eventually finish without overlapping or repeatedly restarting scans.
No credentials or conversation data are included in this report.