Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Codex cost cache scan state is shared across CODEX_HOME profile homes, so scanning one home resets another's coverage

Open
  • Is something wrong?
#4,770 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

@harjothkhara is already working on this.

Since Oct 25, 2026.

  • #4773 by @harjothkhara — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
sqlite, swift
Domain
backend, database

Research direction

Start by tracing the cost cache implementation that writes scan_metadata and discovery_state in cost-usage.sqlite; the issue does not name source files or tests. Check how scan inventory and lookback state are keyed, then reproduce the two-home sequence from the report. Done means each CODEX_HOME retains its own established coverage and cached rows when another home is scanned.

Written by the indexing model from the issue text.

Description

clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:data-loss issue-rating: 🦞 diamond lobster no-stale P2

Summary

With more than one Codex home (codexProfileHomePaths, or CODEX_HOME=… codexbar cost --provider codex), the Codex cost cache keeps a single scan state for all homes. Scanning home B after home A has established coverage sends A back to historyCoverageIsEstablished: false with partial totals. Each later --refresh re-adds A's sessions in batches until coverage is established again.

Details

  • Cache: ~/Library/Caches/CodexBar/cost-usage/cost-usage.sqlite. scan_metadata and discovery_state each hold one row (id = 1), so the scan inventory and lookback state of the last scanned home replace those of the previous one.
  • The menu-bar app scanning profile homes in the background has the same effect on CLI scans, so totals for a home can change between two CLI runs with no CLI scan of another home in between.
  • Setting HOME to another directory does not move the cache, so callers cannot isolate it per home.

Repro (CLI 0.81.0, macOS)

  1. CODEX_HOME=<home A> codexbar cost --provider codex --provider-native-only --days 35 --refresh --format json, repeated until historyCoverageIsEstablished is true (about 5 runs for a home with ~600 rollouts).
  2. CODEX_HOME=<home B> codexbar cost --provider codex --provider-native-only --days 35 --format json once.
  3. Run step 1's command for home A again without --refresh: historyCoverageIsEstablished is false and the 35-day token total drops sharply (in our case to about 6% of the established value). Home B shows the same after a scan of home A.

Expected

The scan state and cached rows are keyed per CODEX_HOME, so each home keeps its established coverage regardless of which home was scanned last.

Related

  • #3125 / #3132: profile-scoped token/cost snapshots were isolated for display; the underlying scan state still looks shared.
  • #3411: scan-since / lookback reseeding on a single account, different root cause.

Workaround we use

Refresh each home until historyCoverageIsEstablished is true immediately before reading it, inside a time budget.

Dominant language
Swift
Stars
22.8k
Forks
2.2k
Avg merge
21h 55m
Merged PRs (30d)
403

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from steipete/CodexBar

All issues in steipete/CodexBar

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.